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

[Nico Williams <[e-mail]>]

On Wed, Apr 08, 2015 at 06:48:36PM -0400, Greg Hudson wrote:
> I do not understand what assumptions would yield a security level of 128
> bits from SHA-256 truncated to 192 bits, and a security level of 192
> bits from SHA-384 truncated to 192 bits.  If there is a concern about
> birthday attacks on the integrity tag, then we can't get away with
> truncating at all; we would need to send a 256-bit tag for the 128-bit
> security level, and a 384-bit tag for the 192-bit security level.

I expect HMAC-SHA-256 with 128-bit HMAC keys provides 128-bit security
against forgeries (which is all we're after if we encrypt-then-MAC) no
matter length the result is truncated to as long as that length is 128
or more bits.

The reason is: the attacker has a 128-bit key search space, and any
forgery attack that requires more work than a key brute-force attack is
not worth it, so using a MAC length of more than 128 bits is not likely
to be useful (it will cause defenders to waste bandwidth) unless there
are forgery attacks at least a few bits better than the MAC length, for
HMAC with any given MAC length.

The critical thing here is the size of the HMAC key.

Perhaps HMAC-SHA256-192 with 192-bit keys could also provide 192-bit
security against distinguishing attacks and forgeries.  But if there are
such attacks depending only attacking the hash against collisions then
HMAC-SHA256-192 can't provide 192-bit security against forgeries -- it
seems prudent to assume such attacks.

ISTM prudent to use HMAC with keys of size matching the advertised
collision resistance of the base hash function and then truncate the
result to that same size.

So, HMAC-SHA256-128 w/ 128-bit keys is OK, but HMAC-SHA256-192 is not
(even if the keys are 192-bit).

Nico
--