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

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Wed, 24 June 2020 17:14 UTC

Return-Path: <prvs=34440d6384=uri@ll.mit.edu>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5195D3A104A for <cfrg@ietfa.amsl.com>; Wed, 24 Jun 2020 10:14:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOrWYLfthCUP for <cfrg@ietfa.amsl.com>; Wed, 24 Jun 2020 10:14:27 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6DDE3A1049 for <cfrg@irtf.org>; Wed, 24 Jun 2020 10:14:27 -0700 (PDT)
Received: from LLE2K16-MBX04.mitll.ad.local (LLE2K16-MBX04.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTPS id 05OHEDVp004561; Wed, 24 Jun 2020 13:14:13 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Yevgeniy Dodis <dodis@cs.nyu.edu>, Paul Grubbs <pag225@cornell.edu>
CC: CFRG <cfrg@irtf.org>
Thread-Topic: [Cfrg] Do we need a selection contest for AEAD?
Thread-Index: AQHWRl+/a1yZqWKXrUWtt9h91T1RYajoQPkAgAAJrQD//75bgA==
Date: Wed, 24 Jun 2020 17:14:12 +0000
Message-ID: <36E536DC-5107-40C7-92CD-17C21F52C37F@ll.mit.edu>
References: <CAMr0u6=QJuG9mshppB6qeryk6qekVKgi9D=WqGoa_L4sNgtYLg@mail.gmail.com> <CAKDPBw8oRZoBzCQv4yfM_QwGyHtqU42VXuV97MytjzsqyQJvcw@mail.gmail.com> <CAMvzKsh4LsnRNkHdhENvn_EQkiNKpi-n8Z7ByKHLDBCrTyyarg@mail.gmail.com>
In-Reply-To: <CAMvzKsh4LsnRNkHdhENvn_EQkiNKpi-n8Z7ByKHLDBCrTyyarg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.37.20051002
x-originating-ip: [172.25.1.85]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3675849251_1644659899"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-24_11:2020-06-24, 2020-06-24 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2004280000 definitions=main-2006240118
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/onphRPfhuX19pQlVpFS0dV0Dbuk>
Subject: Re: [Cfrg] Do we need a selection contest for AEAD?
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jun 2020 17:14:29 -0000

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 dodis@cs.nyu.edu> 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 <pag225@cornell.edu> 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 <smyshsv@gmail.com> 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@irtf.org
    >> https://www.irtf.org/mailman/listinfo/cfrg
    >
    > _______________________________________________
    > Cfrg mailing list
    > Cfrg@irtf.org
    > https://www.irtf.org/mailman/listinfo/cfrg

    _______________________________________________
    Cfrg mailing list
    Cfrg@irtf.org
    https://www.irtf.org/mailman/listinfo/cfrg