IETF Logo Mail Archive

Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Mon, 28 March 2016 23:55 UTC

Return-Path: <prvs=3895e7ef43=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 590A912D0CF for <cfrg@ietfa.amsl.com>; Mon, 28 Mar 2016 16:55:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level:
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 WTD3gDbZlJEe for <cfrg@ietfa.amsl.com>; Mon, 28 Mar 2016 16:55:02 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1388D12D0CC for <cfrg@irtf.org>; Mon, 28 Mar 2016 16:55:02 -0700 (PDT)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u2SNrsuq027242; Mon, 28 Mar 2016 19:53:54 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Ted Krovetz <ted@krovetz.net>, "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document
Thread-Index: AdGJTTy0wUFnuBtreUe1MCzt43wYjg==
Date: Mon, 28 Mar 2016 23:54:59 +0000
Message-ID: <20160328235508.18296912.55938.60348@ll.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="===============1914126760=="
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-28_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1603280357
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/LBJvZytaKD8YSEomMXcyAfuiIQw>
Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
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: Mon, 28 Mar 2016 23:55:04 -0000

I can add to my point:

1. Desire to submit his/her CAESAR submission as an (Informational?) RFC for consideration by IRTF (and possibly later - IETF) is IMHO orthogonal to winning that competition. For example, Blake2 did not win the SHA3 contest, yet there's plenty of interest in having it included in various crypto libraries and protocols. Same goes for Skein. (Yes I know they did go through the process :)

2. It is not clear to me how exactly CAESAR is run, and how (& by who) the winner would be determined. I also don't know how well it held to its own suggested timeline, and how rigid the latter had been. 

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Ted Krovetz
Sent: Monday, March 28, 2016 18:46
To: cfrg@irtf.org
Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document


> I don't want to pre-judge that issue, but it looks to me like it offers
> better performance than the comparable CAESAR candidates, at least on
> hardware with support for AES-NI and PCLMULQDQ instructions. What's your
> thinking on that?


We've seen AEZ achieve peak performance of 0.63 cpu cycles per byte on Intel Skylake and 1.3 cpu cycles per byte on Apple's A9. And because it doesn't use GF(2^128) operations, AEZ is likely much faster than AES-GCM-SIV on other architectures.

I don't want to make any claims of superiority, I just don't understand what the rush is. Once AES-GCM-SIV is an RFC and starts appearing in protocols, it will be very hard to displace, even if it's not the best choice.

Uri suggested that other proposed AEAD schemes interested in short-circuiting the CAESAR process could submit proposed RFCs to CFRG. Is that what you'd like?

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

v2.23.0 | Report a Bug | By Email