RE: [Ipsec] Comment about 3664bis-01

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:housley@vigilsec.com]
> Sent: Tuesday, April 19, 2005 11:50 PM
> To: Eronen Pasi (Nokia-NRC/Helsinki); ipsec@ietf.org
> 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, Pasi.Eronen@nokia.com 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
> >Ipsec@ietf.org
> >https://www1.ietf.org/mailman/listinfo/ipsec
> 
> 

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec