Subject: Re: WG Last Call: SHA-224

From: Jack Lloyd <[email-masked]>
Date: Mon, 29 Mar 2004 12:50:07 -0500

Probably should have sent this to the list in general. I think it's a serious
question if SHA-224 offers any benefit in *any* environment. Are people
seriously rolling out new systems (with new algorithms, such as
SHA-{224,256,384,512}) that are still using 3DES? Seems a bit counterintiutive
(to me) to be changing the hash and not go ahead and swap in AES while you're
at it. If someone really want this and wants it RFCized, then fine, I just
don't see the logic behind it.

In particular, why should the strength of a signature be tied to the strength
of encryption which might be used in the same system? I don't see these as
being logically paired.

-Jack

----- Forwarded message from Jack Lloyd <[email-masked]> -----

From: Jack Lloyd <[email-masked]>
To: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 29 Mar 2004 11:07:41 -0500
Subject: Re: WG Last Call: SHA-224

On Sun, Mar 28, 2004 at 10:52:58AM -0800, Paul Hoffman / IMC wrote:
> 
> bandwidth-restricted environments where an extra 32 bytes is 
> important. None of the documents above discuss any such environments.

32 *bits* you mean. That would have to be one awfully bandwidth-restricted
system, and in any case it's rare (that I've seen) that a hash is sent
directly, either it's used with HMAC (in which case one can use SHA-* and
safely truncate to 96-128 bits regardless of the hash size), or it's used with
a sig, in which case it doesn't matter anyway (an RSA sig with SHA-224 is just
as big as one with SHA-256 or SHA-512 or whatever). In particular the three
drafts being held up by the SHA-224 draft all seem to be for PK, where the
smaller size doesn't offer anything except for possibly reducing the strength
of the signature/encryption.

-Jack

----- End forwarded message -----

---

From: Jack Lloyd <[email-masked]>
Date: Mon, 29 Mar 2004 13:24:27 -0500

On Mon, Mar 29, 2004 at 10:18:43AM -0800, Paul Hoffman / IMC wrote:
> At 12:50 PM -0500 3/29/04, Jack Lloyd wrote:
> >SHA-{224,256,384,512}) that are still using 3DES?
> 
> Yes. TripleDES acceleration chips are much more widely available and 
> tested than AES acceleration chips.

Ah, good point.

-J

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 29 Mar 2004 10:18:43 -0800

>of encryption which might be used in the same system? I don't see these as

You want at least a reasonable match so that the customer knows the 
overall strength of the system.

>system,

Whoops. Quite right. 4 octets.

>  and in any case it's rare (that I've seen) that a hash is sent

Again, this should be noted in the SHA-224 RFC so that people 
designing these protocols will see it.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 30 Mar 2004 15:36:46 +1200

Jack Lloyd <[email-masked]> writes:

>If someone really want this and wants it RFCized, then fine, I just don't see
>the logic behind it.

That's exactly whay I pointed out months ago when it first came up.  It's not
useful in any normal Internet protocol that requires key management because
they all use the output of a PRF (usually via HMAC), it's not useful in
signing because they use PKCS #1, but it is going to be pushed through no
matter what, so we may as well just sit back and..., well, ignore it.  If the
RFC were however to admit that "There's no requirement for this in any
Internet security protocol" (or whatever the text is that gets used for other
oddball algorithms that people do RFCs for) it'd be helpful in addressing
arguments from people who wanted it supported just because it's mentioned in
some RFC.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 31 Mar 2004 04:52:31 +1200

"todd glassey" <[email-masked]> writes:

>This is an instance where this protocol should be a part of the IRTF since it
>will likely not be used in production.

Don't get me wrong, I have no objection to having it as an RFC, but it should
say "We're doing this because it's fun/we have a quota to fill/the mind
control satellites made us/whatever" rather than trying to manufacture a
reason for its existence.  What's wrong with just doing something for the sake
of it?

Peter.

---

From: "todd glassey" <[email-masked]>
Date: Tue, 30 Mar 2004 08:34:16 -0800

This is an instance where this protocol should be a part of the IRTF since
it will likely not be used in production.

Todd

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 30 Mar 2004 10:59:21 -0800

>it will likely not be used in production.

Hmmm, not sure where to start here. The IRTF works on items that are 
intended to be used in production. The IETF sometimes works on items 
that never end up in production. There already was evidence that 
others intend to put this in production, making the prediction much 
less likely to be true.

--Paul Hoffman, Director