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

Re: Summary of changes to HMAC-MD5-96 draft

Rob,

the addition below is not acceptable in the text:

>
>4. In response to the document reading party's comment:
>
>>There is a requirment that "any known attacks" be discussed in the
>>Security Considerations section. The MD5-96-01 doc does not discuss this.
>
>The following as added to paragraph 1 of section 5.
>
>At the time of this writing there are no known cryptographic attacks against
>HMAC-MD5-96.

Of course, THERE ARE such attacks (exhaustive key recovery attack,
MAC guessing attacks, on-line birthday attacks are all cryptographic 
attacks). Even if they are currently impractical they exist.
You should refer to the following text of rfc 2104 or even adapt a part 
of it to your needs here (I stress that this text does apply to the 96-bit
truncated output version used in ipsec).

   The strongest attack known against HMAC is based on the frequency of
   collisions for the hash function H ("birthday attack") [PV,BCK2],
   and is totally impractical for minimally reasonable hash functions.  
 
   As an example, if we consider a hash function like MD5 where the output 
   length equals L=16 bytes (128 bits) the attacker needs to acquire the 
   correct message authentication tags computed (with the _same_ secret key K!)
   on about 2**64 known plaintexts.  This would require the processing of at 
   least 2**64 blocks under H, an impossible task in any realistic scenario
   (for a block length of 64 bytes this would take 250,000 years in a continuous
   1Gbps link, and without changing the secret key K during all this time).
   This attack could become realistic only if serious flaws in the 
   collision behavior of the function H are discovered (e.g.  collisions 
   found after 2**30 messages). Such a discovery would determine the 
   immediate replacement of the function H (the effects of such failure 
   would be far more severe for the traditional uses of H in the context 
   of digital signatures, public key certificates, etc.).

Another part of rfc 2104 that you may want to bring explicitly is:

   Keys need to be chosen at random (or using a cryptographically strong
   pseudo-random generator seeded with a random seed), and periodically
   refreshed.  (Current attacks do not indicate a specific recommended
   frequency for key changes as these attacks are practically infeasible.
   However, periodic key refreshment is a fundamental security practice
   that helps against potential weaknesses of the function and keys, and
   limits the damage of an exposed key.)

Hugo

>
>Rob G.
>rob.glenn@nist.gov
>
>
>



--
John Kelley					johnk@tis.com
Director, Systems Administration
Trusted Information Systems, Inc.  (A NASDAQ company: "TISX")
http://www.tis.com