Additional Proposed Hash Function (Forwarded)

[Jerrold Leichter]

| > | > NIST is proposing a change notice for FIPS 180-2, the Secure Hash Standard
| > | > that will specify an additional hash function, SHA-224, that is based on
| > | > SHA-256. The change notice is available at
| > | > http://csrc.nist.gov/publications/drafts.html. NIST requests comments for
| > | > the change notice by January 16, 2004. Comments should be addressed to
| > | > ebarker at nist.gov.
| > |
| > | Does anyone know what the story is behind this?  It seems to be the
| > | same sort of relationship that SHA-384 has to SHA-512 - that is, the
| > | same basic algorithm, the same amount of work to calculate it, but
| > | with different initial values, and some bits chopped off at the end.
| > | It all seems a lot of effort just to save 4 bytes in the final hash.
|
| > I'd guess that this is part of an effort to define hashes "equivalent in
| > strength" to various standardized ciphers.  Because of birthday attacks, in
| > some sense the security of an n-bit hash is comparable to that of an n/2-bit
| > cipher.  So SHA-256, -384, and -512 are intended to match the three supported
| > AES key sizes of 128, 196, and 256 bits.  SHA-224 then comes out to match
| > 2-key 3-DES.
|
|
| That is the guess we came up with too.  But, why does
| NIST bother to standardise this?
|
| Granted 2-key 3-DES is in widespread use, but it should
| gradually switch across to other ciphers.
Standards bodies are supposed to deal with existing practice.  If you accept
the need for hash functions with sizes "matched" to standardized encryption
techniques, then it's appropriate for them to do this.  (Of course, it raises
the question of why there isn't an SHA-112 to go with DES - but I guess that's
officially deprecated now.)

|                                            And, for a
| stop-gap measure, if a protocol implementor finds a need
| to match a hash size, why not just truncate a SHA-256?
NIST isn't an implementor, its a standards body.  It can't say "just truncate
SHA-256" - it has to say *how*.

In fact, the real question here is why they bothered to change the initial
values.  It does make the SHA-256 and SHA-224 values independent in some
sense, but but I'm not sure exactly *how* independent.  That is:  If I give
you the SHA-256 and SHA-224 hashes on some piece of data, have I given you
something that's effectively a 480-bit hash?  Changing the initial value is
equivalent to prepending some initial fixed block.  The fixed block is
unknown, unless the initial value was *calculated* as the result of one
iteration of SHA over some value.  That's why it's important to know just
where the intial value came from.

| Or, to take the alternate position, if there is a case
| for "wierd lengths," then maybe this is a case that
| SHA could be reworked to be of flexible length, at the
| algorithm level?
Well, this is one place that secure hash function theory is rather weak. All
the hash functions in use have an iterative structure, which implies a prepend
property (i.e., if I know the hash of X, where X is an even multiple of the
block size in length) I can calculate the hash X || Y for any Y, without
knowing X.)  Also, the constructions are size-specific - there's no obvious
way to change the block size or output size - except by keeping a fixed block
size and discarding some part of the final block to produce a smaller output
size.

I think there are some constructions out there without these problems, but
none seem to be practical.  This remains an area waiting for a clever design.

| Defining a new SHA seems to be a lot of detailed work,
| albeit hardly challenging, for everyone involved in
| producing standard crypto, and there doesn't seem to be
| much of a payoff for all those people.
The goal of "a hash to match each encryption", in the abstract, sounds great.
Whether it actually makes practical sense is debatable.  However, once a
standards process gets rolling, the original purposes can fade from view.

							-- Jerry


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com