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

"David McGrew (mcgrew)" <mcgrew@cisco.com> Tue, 30 June 2020 23:42 UTC

Return-Path: <mcgrew@cisco.com>
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 A17773A076C for <cfrg@ietfa.amsl.com>; Tue, 30 Jun 2020 16:42:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=EYHoEHrB; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=sUwf7aeP
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 0aTbFZriw27k for <cfrg@ietfa.amsl.com>; Tue, 30 Jun 2020 16:42:37 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B6103A0745 for <cfrg@irtf.org>; Tue, 30 Jun 2020 16:42:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20765; q=dns/txt; s=iport; t=1593560557; x=1594770157; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2S3Xxu63NJAoq9rV3+tT3UpvqTF40pLlHGJW6NeNxxI=; b=EYHoEHrBt/7qKyZoxPKCJiBZ4r0mi8wsmYb7scoOgroB7fZodlegUTuu AM1RmFoSBbtpOHo/VVvA0EwMwthwGSyfmVCtHaBlmJNQc/L/lwHe00q/n QY9sqy/6lqJOxncKyUneSs/g0BIbVYYnsDq5ZlWj1PGDKrv57Se8sHqco I=;
IronPort-PHdr: =?us-ascii?q?9a23=3AiIQ8ShTjmWWMFgDKYTWvsAM8rtpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBNmJ5PdNiu6QuKflCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFLXq3y2qzUVH0?= =?us-ascii?q?a3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+IQ/wox/Ws5wdgJBpLeA6zR?= =?us-ascii?q?6arw=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CVBQBszfte/4ENJK1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQGCCoFSKSgHb1gvLAqEJ4NGA41LigGJboRrgUKBEANVCwEBAQw?= =?us-ascii?q?BARgBCgoCBAEBhEcCF4F5AiQ4EwIDAQELAQEFAQEBAgEGBG2FWwyFbwEBBAE?= =?us-ascii?q?BEBEdAQEsCwEPAgEIGBUSAwICAh8GCxQRAgQOBRQOgwQBgX5NAy4BDqNxAoE?= =?us-ascii?q?5iGF2gTKDAQEBBYJJgnINC4IOAwaBOIJpiWEeGoIAgREnHIIfLj6CGisXAYE?= =?us-ascii?q?ZDRFWEoJXM4ItkjmGQSabF00KglyRTIMIhG4DHZ8WnkaRZAIEAgQFAg4BAQW?= =?us-ascii?q?BaiKBVnAVOyoBgj5QFwINjh4JGoECAQaCRYUUhUJ0NwIGAQcBAQMJfIx9gTU?= =?us-ascii?q?BgRABAQ?=
X-IronPort-AV: E=Sophos;i="5.75,298,1589241600"; d="scan'208,217";a="791126668"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Jun 2020 23:42:03 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 05UNg372006200 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 30 Jun 2020 23:42:03 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 30 Jun 2020 18:42:03 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 30 Jun 2020 19:42:01 -0400
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 30 Jun 2020 19:42:01 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=e0XF8/yi+HA5yME/7AL33IBkE07HRr+V7EvjLW5zIR1bZGqIMArydLiiNTBehS9H8+OQ93JlT2J5WmDuuWQm4qgrrdu1uzkq455vcilw71EuNNFvF9J/Y0mIZFzw72f8QBACSd5jk0fqBX65y3fk3ZpA8uLUuKWQtMrYql9djYRjrOdHUqwCPQASsxtbQSvxDsHEm9Er713Ikk44HOnLLiM7vU1NVqxUq+/aYbCbDiqaEpGk/D53/zeehcyk4NFj2A6JI3OWo8AJv6LOeg8ndGRrjwxHcgvND+fBRf0CeqUbbmdsfyNpx/Vvcdh3GA7ndlDACITmi8auZIZcNRrWlA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2S3Xxu63NJAoq9rV3+tT3UpvqTF40pLlHGJW6NeNxxI=; b=RM/hdC3ytL+gm4QhFmTrq4BFAKBYI7saUXfVgRIvaoSl+CIlZlAxRWjsmWnR6on5b1QTuQ6Jc+O+tmnIABKEOxQtabP5u/n4RJb8lRJZnf667ubiZ9Kjd1+MPEuax1xAGL0qB956x3CHkOIWBti3wu2ppCB0PkodpGY+DR19uOgDfpfYj8zTpwiLV28QvAX6ZqP4p/m+aCGH3aLd87zfpxh/ejJeC0gKmIrxt4wMK0kKiMkUEwmSkRAzOITgNRZKfEfO7tvgGDQRpUGXQp0ilPz9wvgJWboCqBoCuraVGO20rI+dnlJhneBSpTCl4psZw3hGSAlVQ+iks9XDhuUwvg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2S3Xxu63NJAoq9rV3+tT3UpvqTF40pLlHGJW6NeNxxI=; b=sUwf7aePCOpZntp8bGy97dfLonLfTOVvQFEdYS+HWLfC0kHiBeV8NvWGQb/68IbQ8/vi64NM6MIty0tbJ31vhZHpipvHFKfEobvakV584qR+zInmiDHVETffcpNJOUp14W/cxhH7hizz42p/nQ7hpZWc3H5AmrDywdEj91L4Gtk=
Received: from BL0PR11MB2947.namprd11.prod.outlook.com (2603:10b6:208:33::28) by MN2PR11MB4712.namprd11.prod.outlook.com (2603:10b6:208:264::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20; Tue, 30 Jun 2020 23:42:00 +0000
Received: from BL0PR11MB2947.namprd11.prod.outlook.com ([fe80::3cea:d71b:ea4e:c02a]) by BL0PR11MB2947.namprd11.prod.outlook.com ([fe80::3cea:d71b:ea4e:c02a%2]) with mapi id 15.20.3131.027; Tue, 30 Jun 2020 23:42:00 +0000
From: "David McGrew (mcgrew)" <mcgrew@cisco.com>
To: Mridul Nandi <mridul.nandi@gmail.com>
CC: CFRG <cfrg@irtf.org>
Thread-Topic: [Cfrg] Do we need a selection contest for AEAD?
Thread-Index: AQHWRl+sLJeUiGUMVkyR6yf00MJrvKjn/esAgAAJrQCAAAFrAIAABb2AgAnUmIA=
Date: Tue, 30 Jun 2020 23:42:00 +0000
Message-ID: <F53AA74A-271D-471D-9B2D-EDA9ED08C6A9@cisco.com>
References: <CAMr0u6=QJuG9mshppB6qeryk6qekVKgi9D=WqGoa_L4sNgtYLg@mail.gmail.com> <CAKDPBw8oRZoBzCQv4yfM_QwGyHtqU42VXuV97MytjzsqyQJvcw@mail.gmail.com> <CAMvzKsh4LsnRNkHdhENvn_EQkiNKpi-n8Z7ByKHLDBCrTyyarg@mail.gmail.com> <36E536DC-5107-40C7-92CD-17C21F52C37F@ll.mit.edu> <CAJBmYM_sDQKbf=TamAs2G=e-=3mkG-U+rwmyTu5jGJJM3KaiJw@mail.gmail.com>
In-Reply-To: <CAJBmYM_sDQKbf=TamAs2G=e-=3mkG-U+rwmyTu5jGJJM3KaiJw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.117.65]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 729ccdf0-84f9-4419-a9ad-08d81d4f2f2e
x-ms-traffictypediagnostic: MN2PR11MB4712:
x-microsoft-antispam-prvs: <MN2PR11MB4712303A89C46C97A227A983C96F0@MN2PR11MB4712.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0450A714CB
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: /9Er9D8iyZT0YclAfcZvY54OhmpSlNQEKAmUBaOm0Mm3GYsuYqYrknbilrzV3tBRzAqywL/0HQEiviaPoZmAcEZfkT5tyRq0tTlrc4toFdLVKXfIeBA99Mkmj/OgaMkqnTZ5n7JUeOD0IvRO3SCMSpyUT5hmJE8pe7BDwEKFPUoZLa7AZv6/xAUiNFbDpiZdNNcF6n/JqYG2kksUBUhXOiOy9bqn3XY8r8Ei52tQtWyHmsOy+xryQxtjackx0yhvzK3w2ZD6VCDUryJSoYUKqHi0WDdEWUvAaEQnC0rMMtrRLoCZoMkhhk/Wd5qFEEp+VdXNEaQO6SFhJyV8ZNfHUu9DtBHwEwnPIyfzNvJy79LpHGi6vaK7aTvR1UVmcWKmRZhKxDtV9fcNakU2p0clLsSyyh2jEG8LniJc8Cb1VubvjlsRODsusrce+2LyM30zk2RiWdNWpD8x01gDBB1QoQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB2947.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(376002)(346002)(366004)(136003)(396003)(6916009)(478600001)(26005)(966005)(6512007)(186003)(316002)(6486002)(2616005)(71200400001)(4326008)(66946007)(8936002)(76116006)(53546011)(2906002)(86362001)(36756003)(5660300002)(83380400001)(6506007)(66446008)(64756008)(33656002)(166002)(8676002)(66556008)(66476007)(23603002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: z2Xw/VGyYVjieReVuBUgIdJJ2ol/Lv6Rg9w/yuYeUI0LDHylmnROyeHph61N19+HZjqjwtw8aN3PATjx0BjjQUtg0rhzekijMFwMoPu8qYqPrM4rb/hQ+c0Ty/bFVhxv5RLI5xT5pqeyayvyyJXk39DxYeE/7j4UIJXE41LX8l1wJPGc3TK5nSRgY9AQfVEr1n5UCOnpx2HXarvjoFnh6l6M2UXjJpeqbn9Cu9j1zMGS6D9O4PqHSkMElwBRNFfiAdnw2+8LJxUFNKtqQcdJ6iMsRGPgCLq8g8YSKmjR7qUH9wwzRjOU7itlTq4vwrKZmJeTgiQ3zH0GW0eARE4PnvRZWod40+6+iKj3TLgJEj4K1F4yb00fGsorlwCG7XP0fKbWqYt19yp0WfAILE58pKJFj5Ur79P3gi61TQHVK87YDs6+nRGAvCqM7WRdz5YSh0nGp3B4AWRo+L3SFgOGUkbTozVFqn/5KKMTHxJHB9M=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_F53AA74A271D471D9B2DEDA9ED08C6A9ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB2947.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 729ccdf0-84f9-4419-a9ad-08d81d4f2f2e
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2020 23:42:00.1705 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: AQQawLCys4t7jFyGF2zq+3Soe/lkCKOI+PSe483aFy0ZANNe7mN7k9YcKp7S1/AKMPiSX6XA/RARFqgfiYB54A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4712
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/NDidIXAabVlYUKC2REJ9o6lnpQ4>
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: Tue, 30 Jun 2020 23:42:40 -0000

Hi Mridul,

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

David

On Jun 24, 2020, at 1:34 PM, Mridul Nandi <mridul.nandi@gmail.com<mailto:mridul.nandi@gmail.com>> 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 <uri@ll.mit.edu<mailto:uri@ll.mit.edu>> 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 dodis@cs.nyu.edu<mailto: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<mailto: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<mailto: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<mailto:Cfrg@irtf.org>
    >> https://www.irtf.org/mailman/listinfo/cfrg
    >
    > _______________________________________________
    > Cfrg mailing list
    > Cfrg@irtf.org<mailto:Cfrg@irtf.org>
    > https://www.irtf.org/mailman/listinfo/cfrg

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