Re: [Cfrg] AES-based PRF - comment please

[Uri Blumenthal <uri@bell-labs.com>]

David Wagner wrote:
> > Here's a proposed PRF based on AES block cipher.
> For those who aren't on IPSec mailing list, Hugo Krawczyk and I have
> pointed out that this construction requires something more than just
> the assumption that AES is a PRP -- some additional assumptions are
> required for this construction to be secure.
However we seem to disagree as to what other assumptions - if
any - are necessary. We are currently discussing those off-line,
but if anybody on the list would like to contribute, you're
most welcome!

> In general, I am somewhat skeptical of constructions which assume that
> AES is something more than a PRP; most analysis of AES has been on its
> security as a PRP.
I do not think that a stronger assumption is needed (or indeed can
be made). Being a PRP [family] means that whatever key [PRP family
index] you choose, the specific function is a PRP. Which should be
enough for the proposed construction. I'm in the process of putting
together a more "formal" proof, and again, feel free to jump in.

> Also, in general, given that we already have PRF's with well-justified
> security arguments, I think any new proposal of a PRF ought to come
> with a careful proof of security under some well-specified set of
> assumptions.
It looks that whatever arguments can be made against this construction,
the very same ones apply to the existing PRF's, such as HMAC - because
in case of AES the PRP property is necessary (otherwise it's not an
acceptable block cipher), and in case of SHA it's merely believed
as nobody proved otherwise that it is a PRF (and if it isn't,
it still is an acceptable hash, which it was designed to be).
The existing PRF's security is reduced to that of SHA - and
SHA is LIKELY (but doesn't have to) have the ascribed to
it properties. This construct's security is reduced to
that of AES - which MUST have the ascribed property
(or else it is broken). However as David pointed
out, this reduction is not shown convincingly
yet - which I'm busy with now (David, thanks
for putting me to work :-).

Also the justification for creating a new PRF is simple - if you have
a pure AES-based protocol suite (encryption, integrity, MAC), you may
want to have your PRF also AES-based - especially if crypto hardware
is involved (for example a custom ASIC, where it matters whether
you place another algorithm on the chip).

_______________________________________________
Cfrg mailing list
Cfrg@ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg