Additional Proposed Hash Function (Forwarded)

[Peter Gutmann]

Ian Grigg <iang at systemics.com> writes:

>That is the guess we came up with too.  But, why does NIST bother to
>standardise this?

There'd already been a similar discussion on this topic on another list, every
security standard and protocol already provides for generating 3DES keys via
its PRF of choice, so why create yet another new hash variant for it?  All it
does is create extra complexity for implementors (let's see, was that
SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA224,
SSL_RSA_WITH_3DES_EDE_CBC_SHA512_TRUNCATED_TO_112,
SSL_RSA_WITH_3DES_EDE_CBC_SHA256_WITH_BITS_MISSING, or
SSL_RSA_WITH_3DES_EDE_CBC_SHA384_FOLDED_IN_HALF?).  As a result, it's in
danger of ending up with a de facto profile of "ignore it".  In terms of
implementations of standard protocols (TLS, SSH, S/MIME, PGP, IPsec), I can't
see any use for it that'd justify the complexity and overhead of adding it to
an implementation.

Peter.

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