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

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

I am certainly not arguing for an ad hoc change to the algorithm.

However I do believe that in future we should consider vulnerability to
extension attacks as an unacceptable feature of a digest.

		Phill

> -----Original Message-----
> From: Hugo Krawczyk [mailto:[email-masked]]
> Sent: Friday, July 11, 2003 4:53 PM
> To: Hallam-Baker, Phillip
> Cc: [email-masked]
> Subject: RE: [Cfrg] Re: one question about hash
> 
> 
> 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
> 
> On Fri, 11 Jul 2003, Hallam-Baker, Phillip wrote:
> 
> > 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
> > 
> 

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

---

From: "Anton Stiglic" <[email-masked]>
Date: Mon, 14 Jul 2003 09:39:59 -0400

> extension attacks as an unacceptable feature of a digest.

I have to disagree.   Hash functions like SHA1 were made to be hash
functions, not
constructions that act like a random oracle or a PRF.  Cryptographic hash
functions
are built in a way that they are (hopefully) strongly collision resistant
and one-way,
so far SHA1 seems to satisfy these criterias very well, and that's all we
need!

The compression function of SHA1 seems to act like a good PRF on
finite-length
inputs, so we can use it as a MAC (via SHA1-HMAC) or as a PRF (cascade
construction or HMAC), even though this wasn't it's initial intended use.

The primitive we need to rely on is the compression function, and that's it!

The smaller the primitive that is used is, the more confident I am since we
can
study it more extensively and we need to assume less when applying security
proofs.  For example, we don't need to assume that construction C acts like
a good PRF
on arbitrary inputs, we just need to assume that the subconstruction c used
in C acts
like a good finite-length input PRF, this is better.

We don't need a hash functions that are not vulnerable to extension attacks,
we
just need good compression functions.

--Anton

----- Original Message ----- 
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'Hugo Krawczyk'" <[email-masked]>; "Hallam-Baker, Phillip"
<[email-masked]>
Cc: <[email-masked]>
Sent: Friday, July 11, 2003 7:18 PM
Subject: RE: [Cfrg] Re: one question about hash

---

From: David Hopwood <[email-masked]>
Date: Mon, 14 Jul 2003 18:27:36 +0000

-----BEGIN PGP SIGNED MESSAGE-----

Anton Stiglic wrote:
> I have to disagree.

I don't. It would be quite straightforward to "fix" a digest not to have
this property; if we analyse the compression function as a PRF, it only
requires the inputs to the last iteration of the compression function to
be disjoint from the inputs to previous iterations. This would allow the
digest to be safely used directly, in some applications where less efficient
constructions are currently required. For example, it could be used to
directly instantiate a random oracle on variable length inputs.

That is, it makes the digest more useful, at very little cost (the only
cost is that the input range of the PRF has to be slightly larger than the
block size).

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

---

From: "Anton Stiglic" <[email-masked]>
Date: Mon, 14 Jul 2003 15:58:38 -0400

----- Original Message ----- 
From: "David Hopwood" <[email-masked]>
[...]
> be disjoint from the inputs to previous iterations. 

Can you give the details of your suggestion?
And how it would be better than HMAC?

Thanks,

--Anton