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

[Mridul Nandi <[e-mail]>]

Dear all,

I think we are lacking formal added security requirements of AEAD.
Beyond the classical definition of AEAD, it would be really interesting if
we can list the additional features in a more formal way..   So I like the
idea of "meta-competition" for discussing and prioritizing requirements and
use cases.  After looking at the outcome of the discussion we may decide
whether a competition is indeed helpful or not.  Even if we decide not to
proceed with a competition, the community can try to design satisfying
certain features discussed in that meta-competition..  This would at least
help to understand which features are meaningful and how/where it is
meaningful to pursue further research in this direction.

Thanks and regards,
Mridul Nandi
Associate Professor
Indian Statistical Institute
Kolkata



On Wed, Jun 24, 2020 at 10:44 PM Blumenthal, Uri - 0553 - MITLL <
[e-mail]> wrote:

> I don't support that idea, because different use cases require different
> "optimizations". My use case doesn't care for nonce hiding, but cares very
> much for performance, and for the ability to have defined security bounds
> for truncated synthetic IV.
>
> There is no "one size fits all", or "one champion fits all". Even CAESAR
> results may not be granular enough (several categories, with a winner in
> each one).
>
> Or are you planning to have a *separate* competition for *each* of those
> listed below:
>
>     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 6/24/20, 13:09, "Cfrg on behalf of Yevgeniy Dodis" <cfrg-bounces@irtf..org
> on behalf of [e-mail]> wrote:
>
>     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 <[e-mail]>
> 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 <
> [e-mail]> 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
>     >> [e-mail]
>     >> https://www.irtf.org/mailman/listinfo/cfrg
>     >
>     > _______________________________________________
>     > Cfrg mailing list
>     > [e-mail]
>     > https://www.irtf.org/mailman/listinfo/cfrg
>
>     _______________________________________________
>     Cfrg mailing list
>     [e-mail]
>     https://www.irtf.org/mailman/listinfo/cfrg
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>