[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?
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.