> I'm not sure what you mean by 'not possible to collide' here. Hashes are
> typically smaller than the allowed inputs, which means there must exist
> different input files that produce the
> same output hash. A cryptographic hash just makes those collisions hard to
> find/create, it cannot pre
Folks, if there's something to say about hashes that can be answered by
a quick trip to Wikipedia or your other favorite fount of public
knowledge, please consider doing so... this is discussion, though
liveliness is good, is starting to seem like a significant divergence
from the core purposes
> > One can even construct a general proof:
> > Given a H where it is not possible to collide H(a) = H(b) with a ≠ b
I'm not sure what you mean by 'not possible to collide' here. Hashes
are typically smaller than the allowed inputs, which means there must
exist different input files that produce t
> While I agree that you can certainly find collisions when you do
> crc16(H(a),H(b))
> or
> H(crc16(a),crc16(b))
> I fail to see how that would be possible with cryptographic hash functions
> like SHA-256, so
> H(H(a),H(b))
> especially since the hash functions internally usually work in rounds
somewhat offtopic
On 20/12/2018 09.59, Daniel Shahaf wrote:
> Hash functions are usually defined in terms of collision resistance.
> The constructions above have not been proven to be collision resistant,
> and moreover, they might not *be* collision resistant — even if h() is.
> Therefore, we sho
