Am Donnerstag, 14. Juli 2016, 04:00:57 schrieb Jeffrey Walton: Hi Jeffrey, > > Note, as shared secrets potentially post-processed by a KDF usually are > > again used as key or data encryption keys, they need to be > > truncated/expanded to a specific length anyway. A KDF inherently provides > > the truncation support to any arbitrary length. Thus, I would think that > > the caller needs to provide that length but does not need to truncate the > > output itself. > > As far as I know, there's no reduction in proof that a truncated hash > is as secure as the non-truncated one. One of the reasons to provide > the output length as a security parameter is to help avoid truncation > and related hash output attacks. > > Also see Kelsey's work on the subject; > http://www.google.com/search?q=nist+kelsey+truncated+hash. I understand that point. However, a KDF is not just a simple hash or truncation thereof. Furthermore, Kelsey is part of the NIST team that also developed SP800-108 (the KDF definition). Furthermore, the authors of SP800-56A (in particular Allen Roginsky who I met personally a number of times) work closely with Kelsey too. So, I would not think that applying the standard KDF operation which is intended to "right-size" the DH output is nothing we should worry about. I would rather worry about the size of the private key in the DH operation. The private key should be as small as cryptographically possible (e.g. 224 or 256 bits) instead of half of the DH public key minus one (what TLS does) due to the reduced number of Sopie-Germain primes that are available in the latter case. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
