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

[Greg Hudson <[e-mail]>]

On 04/09/2015 06:21 PM, Michael Jenkins wrote:
> Bit string lengths and bits-o'-security: When this draft was originally
> introduced to kitten, it was stated that it was to support
> draft-burgin-kerberos-suiteb
> <http://www.ietf.org/mail-archive/web/kitten/current/msg03802.html>. So
> there's an implicit presumption that one is working in one of two modes,
> 192-bit or 128-bit security, and consequently using either SHA-384 or
> SHA-256, respectively. 

I am not familiar with what Suite B requires in detail.  Looking at
https://www.nsa.gov/ia/programs/suiteb_cryptography/
I do see that Suite B indicates the use of SHA-384 for TOP SECRET.  I
assume that it requires this because the weakest inherent aspect of a
hash is its collision resistance, and SHA-384 has (we hope) a collision
resistance strength of 192 bits.  Some uses of a hash may not require
collision resistance, but using SHA-384 means you're covered regardless.

However, SHA-384 truncated to 192 bits does not have a collision
resistance strength of 192 bits; it has a collision resistance strength
of 96 bits.  This is described in detail in SP 800-107 section 5.1,
which is referenced by FIPS 180-4 section 7.

I don't think any meaningful review would deem
192-truncate(HMAC-SHA-384(k, m)) to be stronger than
192-truncate(HMAC-SHA-256(k, m)) by any metric.

> In general, though, it's designed to make sense - you can't use SHA-256
> to get a 192 bit key because a SHA-256 output has at most 128 bits of
> security no matter how you slice it.

I think it very much does matter how you slice it.  For key derivation
using an HMAC, collision resistance is not required, so it is entirely
reasonable to use SHA-256 to generate a 192-bit key.  In fact, the key
derivation function used in this draft (from SP 800-108 section 5.1) can
work securely even if more keying material is required than the HMAC
output size.

For the encryption integrity tag and checksum, collision resistance may
be required for Suite B compliance (but I don't really know).  But as
mentioned above, if we're going to truncate the HMAC result down to 192
bits, we cannot achieve collision resistance strength greater than 96
bits no matter what hash function we use in the HMAC.

In conclusion, to the best of my knowledge:

* If the goal is to meet a checklist of Suite B requirements, using
SHA-384 over SHA-256 internally might be necessary, but it really is
just a meaningless checklist tick.  Moreover, the small integrity tag
and checksum lengths could mean that the draft doesn't actually satisfy
Suite B--I can't speak confidently either way on that point.

* If the goal is to achieve some real security strength, using truncated
SHA-384 is not an improvement over using truncated SHA-256.