[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D ACTION:draft-ietf-ipsec-ciph-sha-256-00.txt


There are 2 conflicting concerns here:

 1. having a longer MAC implies that each MAC leaks more information
   on the MAC key (in an information theoretic sense, but for some
   weaker MAC functions such information can be exploited - there
   are no indications that this is the case for HMAC, but it
   never hurts to be careful).
 2. having a shorter MAC means that the MAC string may be easier to
   predict for a given message (for example, it may be that one
   can predict the first 80 bits of a MAC easily, but not the
   full 128 bits).

Personally I believe that the first concern is more important,
as it deals with key leakage while the second concern is about
forging a single MAC.
The "optimal" choice from this viewpoint (based on birthday
attacks) is that the size of the MAC should be exactly half the
size of the hash function output, and that the size of the key
should be the size of the hash output.  This would lead to
choosing a 128-bit output for SHA-256.

For obvious reasons, it does not make sense to choose a
MAC length longer than the key (the opponent just guesses the
key rather than the MAC value).

If I remember correctly, 96 bits was chosen over 80 bits because
of word alignment issues (and because some people worried more
about concern 2).

For choosing MAC parameters, one has to take into account the
lifetime during which the system will be used (rather than the
lifetime of a single key).  I believe that 80-bit MACs are
sufficient for 20 years or more. A MAC of 96 bits may be chosen
for the alignment reasons mentioned above.  A MAC of 128 bits is
fine but probably too conservative;  anything larger is certainly
overkill and may even harm security in the long run.

Bart Preneel

On Wed, 12 Dec 2001, Paul Koning wrote:

> >>>>> "Shoichi" == Shoichi Sakane <sakane@kame.net> writes:
>
>  >> Title : The HMAC-SHA-256-96 Algorithm and Its Use With IPsec
>  >> Author(s) : S. Frankel, S. Kelly Filename :
>  >> draft-ietf-ipsec-ciph-sha-256-00.txt Pages : 8 Date : 16-Nov-01
>
>  Shoichi> the section 5 in RFC2104 says,
>
>  > We recommend that the output length t be not less than half
>  > the length of the hash output (to match the birthday attack
>  > bound) and not less than 80 bits (a suitable lower bound on
>  > the number of bits that need to be predicted by an
>  > attacker).
>
>  Shoichi> is that ok to truncate into 96bit ?
>
> Applying the text from 2104 says "no" and the length should instead be
> 128 or more.
>
> Which makes me wonder: why was 96 chosen for the original 2 HMACs and
> not 80?  80 would be the minimum value that satisfies the guideline
> from RFC 2104.  Should therefore the SHA-2 based HMAC use a length
> greater than 128 bits?
>
> 	paul
>
References: