Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

[Greg Hudson <[e-mail]>]

On 04/15/2015 10:20 PM, Michael Peck wrote:
> In the case of our proposed Kerberos enctypes, we're using the hashes
> with HMAC for message authentication and for a KDF so collision
> resistance is not a factor - in this case, SHA-384 truncated to 192 bits
> appears to add no cryptographic value over SHA-256 truncated to 192 bits.  
> However, our preference would still be to keep the hash choice as is for
> consistency with the Suite B pairing of AES-256 with SHA-384.  This
> could theoretically enable someone using just that option to not even
> need SHA-256, and might also help avoid confusing compliance assessors.

I can accept the reasoning that the choice is about Suite B pairing and
not cryptographic strength.  As Viktor notes, the performance impact of
using SHA-384 over SHA-256 is a mixed bag; it is likely to be slower for
computing derived keys and PRFs, but faster for computing integrity tags
and checksums for large messages.

> Kp is used for the Kerberos pseudo-random function (PRF).  
> RFC3961 states that the PRF output "should be suitable for use in key
> generation" - if i recall correctly, our thinking here was that we
> didn't know what types of keys could potentially be derived from the PRF
> output, so we'd output the full 256 bits (whether the strength of the
> PRF output is actually 256 bits would of course depend on how the
> base-key is generated/derived) in case the PRF might be used to generate
> an AES-256 key - figured no need to drop bits even if our expected
> strength of the enctype overall is 192 bits.

Okay, but why truncate the PRF output at all?  Why not make the PRF
output 256 bits for aes128-cts-hmac-sha256-128 and 384 bits for
aes256-cts-hmac-sha384-192?

Generally speaking, the size of the PRF output is something convenient
to the enctype, and a construction like the RFC 6112 PRF+ is used to
construct however much keying material is necessary by iterating and
truncating the PRF.  There is no need for the enctype to restrict its
output length to the input key length.  (Of course the entropy of the
output is limited to the entropy of the input key.)

For comparison, RFC 4757 defines its PRF as HMAC-SHA1(K, S) and outputs
160 bits for a 128-bit input key.

I agree that Kp should be 256 bits for aes256-cts-hmac-sha384-192; that
was a dumb question.