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

Paul Grubbs <> Wed, 24 June 2020 16:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0283E3A0D1B for <>; Wed, 24 Jun 2020 09:34:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.838
X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7F-EoR4vhwRT for <>; Wed, 24 Jun 2020 09:34:43 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D26EC3A100D for <>; Wed, 24 Jun 2020 09:34:42 -0700 (PDT)
Received: by with SMTP id v19so2161605qtq.10 for <>; Wed, 24 Jun 2020 09:34:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=g.20171207; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ISx326BYH9swOqGOYFQVel2/qOPOGNlQHaPMk/9VXis=; b=kg7Z1HDHcHDltaWiTzIM3XM9as5+b27PvThQecW9ooH0CiwsWkzktnDDbqSvBVBRpg fB85g3id6tnwmFWx1TkBQWlPbBHbA/TfS8+2Zl2wQjjoxyaMbmTds324R/jf0iNc4y0o SSD+FXwUMkZvqYD2qBVqnqPDGIO8NGAdb5CRgJdaeftZhcZk7M7TI1oYm2ztYxGRvv8B ZgeC4s53+afarnKMDEhuhfhPUikgvMKbODSl6ydumWZ+ppuho4mB4d2Dg75Il5dCrjr3 YVNpxvNWdA9vfvxqr1zisG2VC2MtGb/k7VdgvUy1qF6CvXNqaacnEauglfGyRdpWhIHJ 427g==
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; bh=ISx326BYH9swOqGOYFQVel2/qOPOGNlQHaPMk/9VXis=; b=E5+HPUSOAB9HSPdUCtKFyN11dCaSSVjz4Ho9lvDCKqtZeOE2gY3RVuybdOPzYfZex7 5nTuFWG3h8rlKz6SCHrDcsVzt5htTjqAuO69Z+5mzp9yuIWrKVjjTRc7MtrSwzhY1rsv 8iXN9CIfU+gTEGS3EdTACxVRtkASN1Q5TZDaky4ULt9hjPdW94fV92WLwUbzA+9CunMs httKCp3qOlVzC7Tl2Y7AyAbNCMfGU2MB4g+XSDjDZCICBCubMJ3miJi2vO4pooBcC+hD equ/ZGd3UHtc1JwK2qltqUFHzMpLMImj3pZMOeMi7290kA4qq/bbcS0zeoqQjXF13bDL ntGw==
X-Gm-Message-State: AOAM533fqPorNawwks64yoWOLA4q7jj/wBblODtZm6MbMOBVdA4+wOYJ XGrOCaPu+UYhWXsdb6OkFLnE8wpQwfN+fbsND2kFcg==
X-Google-Smtp-Source: ABdhPJxD1hU3jWZeCx1CC3eLBwrPCtso3MMY4JJNZS08OVglq+O+/hECGr4ImEq66uT+GABgtdX+b11nculWTEEq1uU=
X-Received: by 2002:ac8:691:: with SMTP id f17mr7535020qth.60.1593016481528; Wed, 24 Jun 2020 09:34:41 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Paul Grubbs <>
Date: Wed, 24 Jun 2020 12:34:30 -0400
Message-ID: <>
To: "Stanislav V. Smyshlyaev" <>
Cc: CFRG <>
Content-Type: multipart/alternative; boundary="00000000000080d23e05a8d70def"
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 16:34:45 -0000

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 <>

> 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