Sam:
I am happy with the three things that you want. I am not sure we got
to them in the same way.
I think we disagree about the requirements on the hash, mostly
because the consequences of a collision are very different. However,
I think that the paragraphs that Steve has requested will make that
clear for everyone.
Thanks for the timely response.
Russ
At 11:15 AM 11/29/2005, Sam Hartman wrote:
>>>>> "Russ" == Russ Housley <housley(_at_)vigilsec(_dot_)com> writes:
-
Russ> Why is this theoretical stuff important in this context?
Russ> The hash function security requirements in this application
Russ> appear pretty weak to me. It is certainly no where near the
Russ> requirements imposed in the digital signature context, which
Russ> is where I am really worried about a transition away from
Russ> MD5 and SHA-1.
First, I brought up random oracle in an aside to Steve Bellovin. I'm
not sure it particularly matters to this case.
Actually, their use of a hash appears to require a lot more out of the
hash than a digital signature. A digital signature only requires that
there be no collisions. It would be OK for example in most digital
signature models if you leaked all the information about the signed
document in the hash. The attack against digital signatures is that
we could produce some other document that has the same hash as the
signed document.
Here, though, we're trying to use a hash to hide information. The
first preimage assumption says something close to if the hash is good
we won't be able to find all the information in the input to the hash
function. There's a big difference between "all the input," and "some
of the input" or some function of the input. Knowing the hash is
one-way sets an upper bound on how much information it can leak.
So, I know of nothing that asks little of a hash and can be used for
privacy. The only model I know that can be used for privacy is random
oracle and that asks a lot of a hash.
There may be some other theoretical model weaker than random oracle
that describes how a hash can be used to hide data. If so, I don't
know it. Absent such a model, the claim that they aren't asking much
from md5 in the document is incorrect.
Russ> I am unclear what else you want the authors to do. Can you
1) algorithm agility.
2) Remove paragraph about existing md5 attacks not being an issue or
come up with theoretical justification for that paragraph.
3) Use sha-1 or sha-256 instead of md5.
--Sam
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf