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

Taylor R Campbell <campbell+cfrg@mumble.net> Wed, 20 April 2016 02:13 UTC

Return-Path: <campbell@mumble.net>
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 AE7A212EA06 for <cfrg@ietfa.amsl.com>; Tue, 19 Apr 2016 19:13:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.896
X-Spam-Level:
X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] 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 XR1MdzbLWmBQ for <cfrg@ietfa.amsl.com>; Tue, 19 Apr 2016 19:13:38 -0700 (PDT)
Received: from jupiter.mumble.net (jupiter.mumble.net [74.50.56.165]) by ietfa.amsl.com (Postfix) with ESMTP id 180D312EA08 for <cfrg@irtf.org>; Tue, 19 Apr 2016 19:13:37 -0700 (PDT)
Received: by jupiter.mumble.net (Postfix, from userid 1014) id 5285C6031B; Wed, 20 Apr 2016 02:12:08 +0000 (UTC)
From: Taylor R Campbell <campbell+cfrg@mumble.net>
To: Fedor Brunner <fedor.brunner@azet.sk>
In-reply-to: <57148B14.7020507@azet.sk> (fedor.brunner@azet.sk)
Date: Wed, 20 Apr 2016 02:13:36 +0000
Sender: Taylor R Campbell <campbell@mumble.net>
User-Agent: IMAIL/1.21; Edwin/3.116; MIT-Scheme/9.1.99
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <20160420021208.5285C6031B@jupiter.mumble.net>
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/WxSEDG2_-9JQHCSr2TnZt8oI7z8>
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications
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: Wed, 20 Apr 2016 02:13:39 -0000

   Date: Mon, 18 Apr 2016 09:21:56 +0200
   From: Fedor Brunner <fedor.brunner@azet.sk>

   Adam Langley:
   > But there are situations where nonce management is a problem (i.e.
   > where there are multiple machines encrypting with a single key) and,
   > for that, I think AES-GCM-SIV is pretty attractive because one can
   > reasonably use a random nonce.

   https://cr.yp.to/papers.html#xsalsa

   XSalsa20 is Salsa20 cipher with nonce extended to 192 bits. So there is
   no need to manage nonces, they can be generated with RNG. Could you
   please describe applications where you would prefer AES-GCM-SIV over
   XSalsa20+Poly1305

For NaCl crypto_secretbox_xsalsa20poly1305, nonce reuse -- e.g., due
to a buggy random number generator -- is catastrophic: an eavesdropper
learns the xor of two unknown-plaintext messages, or the content of
one unknown-plaintext message given one known-plaintext message, and
can forge arbitrarily many future messages.

For AES-GCM-SIV, nonce reuse enables the attacker to distinguish
duplicate messages from distinct messages, but is not otherwise
harmful.

Resistance to nonce reuse for AEAD is part of why there is an entire
AES-style crypto competition dedicated to AEAD schemes, CAESAR
<https://competitions.cr.yp.to/caesar.html>.  AES-GCM-SIV was not
submitted because it was put together too recently.

The creators of AES-GCM-SIV and chairs of the CFRG evidently decided
that it would be better to sidestep the competition and endorse crypto
that is, lacking hardware support, either unusably slow or vulnerable
to timing side channels, recommending it for general-purpose use on
the internet.

It's easy to say `all the hardware now supports it'.  It's much harder
to audit all the applications you're using to confirm that they
actually take advantage of the hardware support across umpteen layers
of software abstractions and do not render your keys vulnerable to
extraction by someone over the internet with a watch.