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

["David McGrew (mcgrew)" <[e-mail]>]

Hi Mridul,

+1 to the meta-competition.   I like the name :-)

David

On Jun 24, 2020, at 1:34 PM, Mridul Nandi <[e-mail]<mailto:[e-mail]>> wrote:

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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
    >> https://www.irtf.org/mailman/listinfo/cfrg
    >
    > _______________________________________________
    > Cfrg mailing list
    > [e-mail]<mailto:[e-mail]>
    > https://www.irtf.org/mailman/listinfo/cfrg

    _______________________________________________
    Cfrg mailing list
    [e-mail]<mailto:[e-mail]>
    https://www.irtf.org/mailman/listinfo/cfrg
_______________________________________________
Cfrg mailing list
[e-mail]<mailto:[e-mail]>
https://www.irtf.org/mailman/listinfo/cfrg
_______________________________________________
Cfrg mailing list
[e-mail]<mailto:[e-mail]>
https://www.irtf.org/mailman/listinfo/cfrg