Re: [Cfrg] authenticated encryption with replay protection (AERO) - internet draft

David McGrew <> Sun, 05 January 2014 22:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3023E1AD8EC for <>; Sun, 5 Jan 2014 14:46:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -13.14
X-Spam-Status: No, score=-13.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pUbQXWDoS5IS for <>; Sun, 5 Jan 2014 14:46:20 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4D8AF1AD8EB for <>; Sun, 5 Jan 2014 14:46:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4928; q=dns/txt; s=iport; t=1388961972; x=1390171572; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=jQOJyRKnSyRznZSN11YKjUBOPTfCmg+lb/OvYtBFDDE=; b=as/ijnsrnDI9hlMS+/5zG3osDKQ+CuTeb4sYdiMSm+rDOPuyJik0jI7j D7vM+GA1G3zpLPakBO9lUCfXikJMyJxwcodxzs92J2boQ/y0qIC2szZYb x9R56JODEEqHc6F3fGI4DHuVHQ6K7MLqdPHlbzxgnYdcjsMbXrmqeE+EF c=;
X-IronPort-AV: E=Sophos;i="4.95,609,1384300800"; d="scan'208";a="295392741"
Received: from ([]) by with ESMTP; 05 Jan 2014 22:46:11 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id s05MkBsX004870; Sun, 5 Jan 2014 22:46:11 GMT
Message-ID: <>
Date: Sun, 05 Jan 2014 17:46:10 -0500
From: David McGrew <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130922 Icedove/17.0.9
MIME-Version: 1.0
To: Robert Ransom <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: "John Foley (foleyj)" <>, "" <>
Subject: Re: [Cfrg] authenticated encryption with replay protection (AERO) - internet draft
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 05 Jan 2014 22:46:22 -0000

Hi Robert,

On 01/05/2014 12:24 PM, Robert Ransom wrote:
> On 1/2/14, David McGrew <> 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
>> 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 (‘count the bits’) used in the draft is adequate, as
> long as it is used with care.  (It can be abused: section 4 (PDF page
> 6) of <> 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.)

Agreed.   Well, with AERO, it is not quite counting the number of bits, 
but rather counting the number of sequence numbers that the replay 
checking algorithm would accept.

> (In other constructions, simply ‘counting the bits’ may require 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?

I do not agree that the terms are "rather nasty"; an IPR specialist 
would likely describe them as "defensive", in the sense of [1]. They 
say: " ... Cisco will not assert any patents owned or controlled by 
Cisco against any party for making, using, selling, importing or 
offering for sale a product that implements the standard, provided, 
however that Cisco retains the right to assert its patents (including 
the right to claim past royalties) against any party that asserts a 
patent it owns or controls (either directly or indirectly) against Cisco 
... " [2]   If you or your employer have suggestions on how the details 
of the terms can be tweaked in a way that makes the technology more 
accessible to other companies (that don't sue us), I encourage you to 
email the contact address in the IETF IPR disclosure (which is

Like most employers, mine asks that I not make public statements or 
speculations about the scope of patent claims.



[1]  The Defensive Patent License and Other Ways to Beat the Patent 
System, Julie Samuels, EFF,

[2] Cisco's Statement about IPR related to draft-mcgrew-aero-00,

> Robert Ransom
> .