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

Re: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96 from SHOULD toSHOULD+

Hugo Krawczyk wrote:
 >>> I see no need for further I-D's. As I said in a recent message all
 >>> is needed is a pointer to the AES-XCBC-MAC draft for the definition
 >>> of what ikev2 calls PRF_AES128_CBC. All other issues regarding the
 >>> use of prf are taken care by the ikev2 draft itself.
 >> Respectfully disagree.
 > care to explain?

Of course.

First - a fundamental question. The draft (page 26, section 2.14) uses
Ni | Nr as a key to PRF, and g^ir as data. I understand that for an
essentially keyless function like SHA1 (and HMAC) it doesn't really
matter in what sequence to grok the inputs. However when you use a
keyed algorithm (such as AES), then doesn't it matter what data
(and of what randomness and secrecy) you use as a key, and
what - as a plaintext to crunch?

Second, as far as I know, all the security proofs around block
ciphers are assuming that the key is secret. If one is using
AES-XCBC-MAC as PRF, following section 2.14 (page 26), then
the key is known. What kind of security proofs are you
getting? How secure is XCBC-MAC with a known key?

Third, in our public discussion with David Wagner and Ran Canetti,
David mentioned the "belt and suspenders" approach: a semi-provable
PRF, based on the assumption that as long as EITHER Decisional
Diffie-Hellman holds OR hmac behaves as a random oracle - the
PRF constructed of hmac is secure. What assumptions are
taken with AES-XCBC-MAC used as PRF?

 >>> In particular, the draft completely specifies the use of prf's
 >>> whether with variable length key (such as HMAC-SHA) or fixed
 >>> length key (such as aes128-cbc).
 >> Except for how to construct a pure AES-based PRF.
 > what do you mean by "pure AES-based PRF"? Isnt AES-XCBC
 > a pure AES-based prf?

In my understanding, it is "pure AES-based", but under the
assumptions I see in the draft - not necessarily a PRF due
to its key being publicly known.