Earlier quoted context omitted.
> there may be some hash functions for which H(concat(a, a)) = F(H(a)) I'll give a shot at why this implies that H is not a secure hash function, though I could be wrong. The outputs of a secure hash function should be randomly distributed across the set of all possible outputs. If H is a secure hash function that outputs a value in the set {0,1}^128 (a 128 bit output), then H(a) and H(a+a) should both be 128 bit out…
I don't think this follows. "Random output" is an idealized model that no actual, specific hash function achieves. I already said that having such an F would worry me, but "if F is computable, H is not secure" is a strong statement and I'm wondering whether it's backed up by math, not-quite-math-but-good-reasoning, or handwavy bluster. Please don't take this as an attack, though - I appreciate the attempt!
McGill will double your password if you don’t do it first
151–152 of 152 posts
Re: McGill will double your password if you don’t do it first
#152Earlier quoted context omitted.
I don't think this follows. "Random output" is an idealized model that no actual, specific hash function achieves. I already said that having such an F would worry me, but "if F is computable, H is not secure" is a strong statement and I'm wondering whether it's backed up by math, not-quite-math-but-good-reasoning, or handwavy bluster. Please don't take this as an attack, though - I appreciate the attempt!
I don't think I'm able to make a much more rigorous argument, but I will note that you seem to be applying two different criteria here. If you want to criticize modeling a hash function as a PRF as too idealized, then you aren't going to get a mathematical answer (since it will start with "let H be a PRF").