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

[Thomas Peyrin <[e-mail]>]

As a co-designer of Deoxys, my view is obviously biased here. I think a
competition will only be successful if we have people submitting schemes
(that's very easy) and much more importantly people analyzing them (that's
very hard). Are we sure that we currently have the manpower and enough
incentives to bring researchers around the world to work on that ?

I speak as a researcher that worked on designing schemes and trying to
break others during competitions. Cryptanalysis is a very very unrewarding
task: if you work a lot and eventually manage to break a crypto competition
design (lucky situation), you will actually get a paper and it will never
be cited (the design is dead). Most of the time, you spend weeks/months
trying to break a design and nothing comes out, and sometimes it really
feels like you wasted your time. My point is that cryptanalysis work is the
most valuable asset here, and I don't think we should ditch all the
cryptanalysis work that was provided during the CAESAR competition. First,
because it would be a waste, and secondly because it would send quite a
negative message to all people actually doing the cryptanalysis work. Why
would I spend time on breaking designs if in the end the competition
results are kind of ignored?

As a side point, CAESAR was organized generally by the symmetric-key crypto
community and was already focusing on just 3 use-cases. Even with that, I
would say in general it didn't get the traction that everyone hoped for. I
fear that with a competition with many targets, this will get even worse.
Perhaps a way to go would be to check what use-cases are already handled by
existing designs (I think most of them already have a satisfactory scheme)
and do specialized competitions for more recent and more exotic security
notions ? This would focus the manpower where it is actually needed.

Regards,

Thomas.


Le jeu. 25 juin 2020 à 01:14, Blumenthal, Uri - 0553 - MITLL <[e-mail]>
a écrit :

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