MIME-Version: 1.0
In-Reply-To: <52C60713.6030204@cisco.com>
References: <52C60713.6030204@cisco.com>
Date: Sun, 5 Jan 2014 09:24:09 -0800
Message-ID: <CABqy+soV43iB+qZ2mA49g1pntjXsZrr8Wh3ukvmPD+DCAHh8hg@mail.gmail.com>
From: Robert Ransom <rransom.8774@gmail.com>
To: David McGrew <mcgrew@cisco.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "John Foley \(foleyj\)" <foleyj@cisco.com>, "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] authenticated encryption with replay protection (AERO) -
 internet draft
Precedence: list

On 1/2/14, David McGrew <mcgrew@cisco.com> wrote:
> Hi CFRG,
>
> I have a new proposal for authenticated encryption, which is
> particularly well suited for communication security.   An internet draft
> describing the idea has been published at
> http://tools.ietf.org/html/draft-mcgrew-aero-00 and I would like to
> request a slot at the upcoming CFRG meeting to present this work. (I am
> assuming that we will be meeting in London in March along with IETF
> 89).   I alluded to this work on the thread about misuse resistant
> authenticated encryption earlier today.
>
>  From the draft:
>
> Authenticated Encryption with Replay prOtection (AERO)
>
>     This document describes Authenticated Encryption with Replay
>     prOtection (AERO), a cryptographic technique that provides all of the
>     essential security services needed for communication security. AERO
>     offers several advantages over other methods: it has more compact
>     messages, provides stronger misuse resistance, avoids the need to
>     manage implicit state, and is simpler to use.  This document defines
>     a particular AERO algorithm as well as a registry for such
>     algorithms.
>
> Comments are welcome, and I especially encourage discussion about the
> appropriate goals for authenticated encryption.  The draft explains the
> rationale well enough, I believe, though it does not mention decryption
> misuse.   I will send a separate note on that topic.
>
> A formal proof of security has not yet been published, but is believed
> to be possible, and the draft does include a security analysis.

Since AERO uses a large-block block cipher, I believe that the
folklore approach (=E2=80=98count the bits=E2=80=99) used in the draft is a=
dequate, as
long as it is used with care.  (It can be abused: section 4 (PDF page
6) of <https://www.cl.cam.ac.uk/~rja14/Papers/robustness.pdf> gives
the example of a standardized protocol which relies on a
replay-prevention counter for part of its message redundancy
(i.e. authentication), but obtains only one bit of redundancy due to
poor design of the replay-prevention mechanism.  Fortunately, the
standard replay-prevention practice in modern protocols would not have
introduced that weakness, and AERO uses the modern standard practice.)

(In other constructions, simply =E2=80=98counting the bits=E2=80=99 may req=
uire some
theoretical justification, and/or may produce the wrong result.  For
example, in Poly1305-AES, verification is equivalent to recovering s
from the MAC, decrypting it, and checking the result for equality to
the nonce; if w nonces are to be accepted when verifying a single
message, that is equivalent to allowing the attacker to try w times as
many forgery attempts; and the security bounds published for
Poly1305-AES turn out to have a term linear in the number of forgery
attempts (denoted D in the paper).  But the other term (probability of
distinguishing AES from a uniform random permutation after C + D
queries) is also a function of D, and is not necessarily linear in D.)


I noticed that there are IPR disclosures for AERO, with rather nasty
terms.  Exactly what parts of AERO are claimed by the patent and
patent application listed there?


Robert Ransom