> 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. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
