Ian Grigg <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
