[14873] in cryptography@c2.net mail archive
Re: Additional Proposed Hash Function (Forwarded)
daemon@ATHENA.MIT.EDU (Peter Gutmann)
Sun Dec 7 11:56:39 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Sun, 7 Dec 2003 19:00:44 +1300
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: iang@systemics.com
Cc: cryptography@metzdowd.com
Ian Grigg <iang@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@metzdowd.com
