Subject: RE: [Cfrg] Re: one question about hash

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 11 Jul 2003 07:03:53 -0700

Following on from Hugo's question This is an issue that has always troubled
me about the MD5 and SHA1 itteration functions. I would prefer it if there
was some significant difference between the itteration step and the result,
something that simply cannot be constructed from normal operation

For example changing the way in which the chaining variables are transmitted
from one step to the next for the final iteration of the compression
function. This could be as simple as a permutation on the chaining
variables, H0' = H1, H1'= H2 etc...

For the HTTP digest spec I put the output of the message digest through the
message digest function again concatenated with a bunch of other values as a
way to achieve this same effect.

Even so I would prefer to see the message extension issue eliminated
entirely, I don't think it is an acceptable property for a cryptographic
primitive.

		Phill

_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: Hugo Krawczyk <[email-masked]>
Date: Fri, 11 Jul 2003 23:52:54 +0300 (IDT)

If the extension attacks bother you can use hmac or append a key.

Without entering into the specifics of your proposal, I would caution
against heuristics that "seem to work" or intuitively improve a given
function. Intuition is very misleading in this area. In particular, keep
in mind that one main reason for the way these functions chain the
intermediate results is to ensure the collision-resistance of the iterated
function on the basis of the colision resistance property of the
compression function (the "Merkle-Damgard Theorem"). Also this form of
chaining proves useful in building a prf (or mac) out of these funtions
based on the properties of the compression function.

Any deviation from the original design and usage goal of these functions
needs to be carefully anlyzed. We do not have strong enough ways to
validate the basic design of crypto functions (except for the relative
comfort given by years of cryptanalysis), but we do have a
well-established methodology (via reductions) to relate the properties of
a given cryptographic scheme to the (assumed) properties of the underlying
cryptographic primitive.

Hugo