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

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Fri, 19 June 2020 18:34 UTC

Return-Path: <prvs=34391a244d=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 6853B3A0CD8 for <cfrg@ietfa.amsl.com>; Fri, 19 Jun 2020 11:34:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 KdwFSxcoqxCJ for <cfrg@ietfa.amsl.com>; Fri, 19 Jun 2020 11:34:13 -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 4B2B83A0CB5 for <cfrg@irtf.org>; Fri, 19 Jun 2020 11:34:13 -0700 (PDT)
Received: from LLE2K16-MBX01.mitll.ad.local (LLE2K16-MBX01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTPS id 05JIY6Ib026507; Fri, 19 Jun 2020 14:34:06 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>, Thomas Peyrin <thomas.peyrin@gmail.com>
CC: CFRG <cfrg@irtf.org>
Thread-Topic: [Cfrg] Do we need a selection contest for AEAD?
Thread-Index: AQHWRl+/a1yZqWKXrUWtt9h91T1RYajgeYcA//++LgCAAEpIgP//vaEAgABF2QD//740AA==
Date: Fri, 19 Jun 2020 18:34:04 +0000
Message-ID: <8A3C8943-3B1A-41BA-9B17-45B070523569@ll.mit.edu>
References: <CAMr0u6=QJuG9mshppB6qeryk6qekVKgi9D=WqGoa_L4sNgtYLg@mail.gmail.com> <CAA0wV7TXftZXeteCy3=N_4ezXRTL852_R1kCCPYGFEhQNHGw2Q@mail.gmail.com> <4CFDB50C-6281-4AC8-A9DF-D0F79BF58C5C@ll.mit.edu> <CAA0wV7SjS8OA+QEPN6Dip09Y2Sp5=4WJkTVkRa2O0gnZf_m54w@mail.gmail.com> <924F2899-4D89-4691-80DD-73FD9EDAA520@ll.mit.edu> <BN7PR11MB2641312028C25C3E71713065C1980@BN7PR11MB2641.namprd11.prod.outlook.com>
In-Reply-To: <BN7PR11MB2641312028C25C3E71713065C1980@BN7PR11MB2641.namprd11.prod.outlook.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.90]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="B_3675422044_1621155739"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-19_20:2020-06-19, 2020-06-19 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-2006190135
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/qZGgUqcPSkXB4KxcESkXoqYEPZU>
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: Fri, 19 Jun 2020 18:34:16 -0000

The other thing of concern is “once you’ve found one forgery, how difficult is it to find another?”  For some AEAD’s (GCM, Poly1305-based), it’s easy; for other AEADs (HMAC-based), it’s not.

 

True. Thankfully, not in my use case – but of interest in general. 

 

Though, the cost of doing HMAC on each and every operation may (at least in some use cases) outweigh the risk of having subsequent forgeries “easy”. Of course, it would be nice to have a quantitative expression of that “ease”.

 

TNX!

 

From: Cfrg <cfrg-bounces@irtf.org> On Behalf Of Blumenthal, Uri - 0553 - MITLL
Sent: Friday, June 19, 2020 2:20 PM
To: Thomas Peyrin <thomas.peyrin@gmail.com>
Cc: CFRG <cfrg@irtf.org>
Subject: Re: [Cfrg] Do we need a selection contest for AEAD?

 

Yes. We recommend to use a tag size of 128 bits for our mode, 

 

Yes I realize that. ;-)

 

but in case a smaller tag size \tau is required, the security claims will drop according to \tau.

 

Could you please provide the exact relationship between \tau, number of messages (or encrypted blocks), and, e.g., the probability of collision? I’m looking for the formulas binding those together.

 

Thanks!

 

 

---------- Forwarded message ---------
De : Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu>
Date: sam. 20 juin 2020 à 01:51
Subject: Re: [Cfrg] Do we need a selection contest for AEAD?
To: Thomas Peyrin <thomas.peyrin@gmail.com>, Stanislav V. Smyshlyaev <smyshsv@gmail.com>
Cc: CFRG <cfrg@irtf.org>

 

Can you provide/compute security bounds for truncated synthetic IV?  Some (niche) use cases require it.

 

From: Cfrg <cfrg-bounces@irtf.org> on behalf of Thomas Peyrin <thomas.peyrin@gmail.com>
Date: Friday, June 19, 2020 at 1:47 PM
To: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Cc: CFRG <cfrg@irtf.org>
Subject: Re: [Cfrg] Do we need a selection contest for AEAD?

 

Dear all, 

 

I will be actually sending an RFC draft of Deoxys in the coming weeks like I promised a few months ago (really sorry, with the COVID-19 confining with young kids at home, I couldn't advance on it). It will contain misuse resistant mode (with stronger guarantees than AES-GCM-SIV), leakage resilient mode with different levels of resilience, the possiblity to encrypt 2^124 bytes per key. We are currently analyzing the INT-RUP security of it. All this for about the same efficiency as AES-GCM-SIV.

 

Regards,

 

Thomas.

 

 

Le sam. 20 juin 2020 à 01:32, Stanislav V. Smyshlyaev <smyshsv@gmail.com> a écrit :

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