Subject: RE: [Ipsec] Comment about 3664bis-01

From: [email-masked]
Date: Wed, 20 Apr 2005 08:48:05 +0300

I fully agree; that was just an example pointing out that 
unless we use a real "randomness extractor", there will 
be keys that are secure with all other PRFs, but not with 
AES-XCBC-MAC. 

Best regards,
Pasi

> -----Original Message-----
> From: ext Russ Housley [mailto:[email-masked]]
> Sent: Tuesday, April 19, 2005 11:50 PM
> To: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]
> Subject: Re: [Ipsec] Comment about 3664bis-01
> 
> 
> Pasi:
> 
> The probability that all of the blocks are identical seems 
> very slim to me.
> 
> Russ
> 
> At 06:37 AM 4/19/2005, [email-masked] wrote:
> >draft-hoffman-rfc3664bis-01 says:
> >
> > > The key for AES-XCBC-PRF-128 is created as follows:
> > >
> > > o  If the key is exactly 128 bits long, use it as-is.
> > >
> > > o  If the key has fewer than 128 bits, pad it on the right with
> > >    zero bits until it is 128 bits long.
> > >
> > > o  If the key is 129 bits or longer, call the first 128 bits
> > >    TKEY (temporary key) and the remaining bits TDATA (temporary
> > >    data).  If TDATA's length is not a multiple of 128, pad TDATA
> > >    on the right with enough 0 bits to make its length an exact
> > >    multiple of 128. Encrypt each 128-bit block of TDATA with TKEY
> > >    using AES-128-EBC as the cipher.  When finished, XOR the
> > >    resulting blocks in the same order as they were created.
> >
> >This way of using ECB mode fails horribly if, for instance,
> >the input contains contains 128 bits of entropy, but for some
> >strange reason consists of three copies of the same 128-bit
> >block: the output would always be zero.
> >
> >What we really need here is a "randomness extractor" that
> >produces a 128-bit output with sufficient entropy (with some
> >suitable definitions of "sufficient" and "entropy") when
> >given _any_ input with sufficient entropy, even if the input
> >contains some known/guessable bits and/or structure.
> >
> >IKEv2 already assumes that AES-XCBC-PRF is a reasonable
> >randomness extractor (when the key is chosen randomly), so
> >something like this would IMHO be better:
> >
> >    o If the key is 129 bits or longer, call the first 128 bits
> >      TKEY (temporary key) and the remaining bits TDATA (temporary
> >      data). Calculate AES-XCBC-PRF-128(TKEY, TDATA) and use
> >      the output as the key.
> >
> >But the assumption made here is slightly different from normal
> >IKEv2 (where the key is Ni/Nr), so probably we should ask some
> >crypto experts (Hugo, are you listening? :-) about this.
> >
> >Also, I'm not sure if doing this step only when the key is
> >longer than 128 bits causes some problems, or whether it would
> >be better to do it always (but then it would not be
> >backwards-compatible with 3664 anymore).
> >
> >Best regards,
> >Pasi
> >
> >_______________________________________________
> >Ipsec mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/ipsec
> 
> 

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Apr 2005 09:47:39 -0700

The (unstated, I admit) design goal was to use only one crypto 
algorithm in AES-XCBC-PRF-128. That is why I used AES as the mixing 
function. Pasi has pointed out a real problem: if the key consists of 
128 bits followed by an even multiple of 128 bits, and each 
consecutive pair of that even multiple consists of two copies of the 
same 128 bits, the resulting key will be all zeros.

There are two ways around this for keys longer than 128 bits:

- Use a different crypto algorithm. For example, "hash the longer key 
with MD5 and use the result" is both easy to describe and simple to 
implement. However, it means adding MD5 code.

- Call AES-XCBC-PRF-128 with the key being the first 128 bits of the 
original key. Fortunately, this is not recursive. :-)

I think the latter meets the design goal fairly well. Does any have 
any problems with this?

--Paul Hoffman, Director
--VPN Consortium