Re: [Cfrg] Do we need a selection contest for AEAD?

Yevgeniy Dodis <> Wed, 24 June 2020 17:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3827D3A0DAB for <>; Wed, 24 Jun 2020 10:09:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oRGyGKabBQtL for <>; Wed, 24 Jun 2020 10:09:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B0A6F3A103E for <>; Wed, 24 Jun 2020 10:09:19 -0700 (PDT)
Received: by with SMTP id j16so2743406ili.9 for <>; Wed, 24 Jun 2020 10:09:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=svlVbTfpuQ5tVJdwwzTh/3c4FEJ1gyMNS/mEKZvOZDo=; b=Fd1QC2cKW6Ov0WbyDtbwMTeqceJQRD0/QQQlzecaROoIwjyl2xrdWLSKhdTQARrwhZ Pk3gdARrdoR2omAfEX8xTeMrvqSP2qKh0ZGHErlF8iIhp7/Kbl9k+SIFQvX+nqBFlwcP WFCChmB45iNXfxUgUoUJkx8T+8KmhzRDLpbkUz2c2vAmf1TvbAF3YYXsEMXBmCgC9H9Y lMIEQPAylYE+hhQIfDIqFhMmIM697Fw8Eq9yCbTcIzX1DDF3yTT8zT8vbR8Y8lmgZ6Bn 0WX+LZIgnB/OBYxvXDD2cianQHTF94aN85/u7R14UvT7vNlTGmX3KQp+Rq9eUaNeR/sF Evcw==
X-Gm-Message-State: AOAM531BSk10L6LT1Gyam7UWQleNimMze9MA8vh8/dY0j7EDgyIELWaa JwZZMeB/SJR96uGc6GvEIr6kxlYyIiFqd2MdUfs=
X-Google-Smtp-Source: ABdhPJwTVf+E4NVjYU9KjkPXznHSfEa0sCUDtTkifXcgPNncrDAALyW3sPZPM+my/cu3e1aEQbweujlbSWNaZNruu/w=
X-Received: by 2002:a05:6e02:48e:: with SMTP id b14mr9575853ils.143.1593018558730; Wed, 24 Jun 2020 10:09:18 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Yevgeniy Dodis <>
Date: Wed, 24 Jun 2020 13:09:08 -0400
Message-ID: <>
To: Paul Grubbs <>
Cc: "Stanislav V. Smyshlyaev" <>, CFRG <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Cfrg] Do we need a selection contest for AEAD?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Jun 2020 17:09:21 -0000

I support Paul's idea. I feel AEAD landscape is getting a bit out of
hand, even despite the CEASAR competition.
Would be good to bring back more structure and understanding, so when
people in the industry need an AEAD scheme,
they have a clear guide what to choose from. Whether this is
committing, remotely-keyed, ZK-friendly, lightweight,
side-channel-resistant, nonce-misuse resistant, nonce-hiding,
beyond-birthday, etc.

On Wed, Jun 24, 2020 at 12:34 PM Paul Grubbs <> wrote:
> I think an AEAD competition is a great idea. Recently I've been studying the AEAD landscape, and there seem to be a lot of gaps between the needs of applications/protocols and the properties widely-used schemes provide. To address this and get a sense of which needs are most pressing, it might be good to have the first round be more of a "meta-competition" for discussing and prioritizing requirements and use cases. The result of this would be an (ideally small) list of well-defined design targets, for which people can propose schemes in subsequent rounds.
> I'd also like to suggest another use case for AEAD: ZK-friendly AEAD modes. These modes would be compatible with efficient ZK proof systems and would make it easy to prove properties of plaintexts in zero knowledge.
> On Fri, Jun 19, 2020 at 1:32 PM Stanislav V. Smyshlyaev <> wrote:
>> Dear CFRG,
>> The chairs would like to ask for opinions whether it seems reasonable to initiate an AEAD mode selection contest in CFRG, to review modern AEAD modes and recommend a mode (or several modes) for the IETF.
>> We’ve recently had a CAESAR contest, and, of course, its results have to be taken into account very seriously. In addition to the properties that were primarily addressed during the CAESAR contest (like protection against side-channel attacks, authenticity/limited privacy damage in case of nonce misuse or release of unverified plaintexts, robustness in such scenarios as huge amounts of data), the following properties may be especially important for the usage of AEAD mechanisms in IETF protocols:
>> 1) Leakage resistance.
>> 2) Incremental AEAD.
>> 3) Commitment AEAD (we've had a discussion in the list a while ago).
>> 4) RUP-security (it was discussed in the CAESAR contest, but the finalists may have some issues with it, as far as I understand).
>> 5) Ability to safely encrypt a larger maximum number of bytes per key (discussed in QUIC WG)..
>> Does this look reasonable?
>> Any thoughts about the possible aims of the contest?
>> Any other requirements for the mode?
>> Regards,
>> Stanislav, Alexey, Nick
>> _______________________________________________
>> Cfrg mailing list
> _______________________________________________
> Cfrg mailing list