RE: WG Last Call: SHA-224

["Alice Sturgeon" <sturgeon@xxxxxxxx>]

Hi Paul, Tim, Russ et al.,

My colleague Bob Jueneman and I have been following this thread with great
interest and some concern, the latter already reflected in the thread,
Paul's post below and some of today's more recent ones.

We agree with Paul's views generally on this subject, in terms of the
usefulness of SHA-224 and the potential impact of its standardization.

We are strongly opposed to standardizing SHA-224, and at present have no
plans to implement it even if it does become a standard.  It seems highly
unlikely that 32 bits would make a substantial difference, even in a
restricted bandwidth environment.  And because the SHA-224 is simply a
truncation of SHA-256, it certainly isn't saving any time.  Its sole purpose
seems to be to fine-tune an "impedance match" with a triple-DES key, when
triple-DES itself is effectively passe and obsolete, notwithstanding the
fact that many applications still use it.

Standardization groups need to remember that there is a cost, often
considerable, to adding features that someone thinks are needed (or simply
that someone thinks are cool), and that, at the end of the day, are not used
in sufficient volume to warrant these costs, of standardization, enabling
interoperability among all the parts.

It sometimes seems that, when an RFP comes up for bid, the race is on to see
who can offer the most features and is compliant with the many standards
that are referenced.  Unfortunately, in a lot of cases neither the RFP
preparers nor the award committee are experts on the fine points of the
standards, and so they simply look at the list of standards and apply a
check-box score to the results.

This inevitably leads to more and more bloated code, more and more potential
errors, and hence more opportunities for security flaws, etc. And in the
case of SHA-224 all of this is done to save 32 bytes, which a protocol
designer could do themselves if they thought it was really, really
important.

But in addition to the problem of bloated code, there is a much more serious
issue of interoperability testing, because for every new "feature" of this
type there is a combinatoric* explosion of interfaces to be tested.  That in
turn drives up the cost of the product, and inescapably drives down the
quality, for there are never sufficient testing resources to go around.

That's why we oppose the standardization of SHA-224, or the use of it in any
IETF protocols, including the ANSI X9.82 Random Number Generation standard
currently being developed.

Having gone this far, we might also question the need for AES-192, SHA-384,
or the corresponding strength elliptic curves as well.  From the timing data
that we've seen, none offers any great savings in time, and in our view the
differences in space are hardly worth it.

As Paul says, these trains may have already left the station but just to let
you know that we jumped off.

(*  Word thinks that "combinatoric" is not a word.  But Google thinks that
it is, and informs you that you can buy one on eBay! :) )


Alice Sturgeon

System Policy Architect
SPYRUS

Chair, Canadian Advisory Committee - IT Security
ISO/IEC JTC 1/SC 27

Phone:  613-232-2350
Cell:  613-291-0331




-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]On
Behalf Of Paul Hoffman / IMC
Sent: Sunday, March 28, 2004 1:53 PM
To: Tim Polk; ietf-pkix@xxxxxxx
Subject: Re: WG Last Call: SHA-224


At 4:14 PM -0500 3/26/04, Tim Polk wrote:
>This specification will provide a stable reference for the SHA-224
>algorithm, which is needed by several IETF specifications.

In searching the Internet Drafts directory, only four documents even
mention SHA-224:

eastlake-xmldsig-uri: uses it as part of an exhaustive list, not a
requirement

pkix-rsa-pkalgs: uses it as part of an exhaustive list, not a requirement

pkix-sha224: the document in question

smime-cms-rsa-kem: uses it but does not justify why it needs it
instead of SHA-256

The train may have left the station on this one, but it is really
pretty silly. The only possible use is in severely
bandwidth-restricted environments where an extra 32 bytes is
important. None of the documents above discuss any such environments.

It is silly to say that SHA-256 doesn't "match" 112 bits of
encryption strength. There is no disadvantage to having more bits of
randomness, particularly because TripleDES doesn't use 112-bit blocks.

This document would be well-served to have an additional paragraph
explaining that systems that use TripleDES and need a matching hash
algorithm SHOULD use SHA-256, not SHA-224, unless they are in
severely bandwidth-restricted environments.

--Paul Hoffman, Director
--Internet Mail Consortium