[Ipsec] Comment about 3664bis-01

[[e-mail]]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipsec