Re: [CFRG] Call for adoption for draft-denis-aegis-aead

Taylor R Campbell <campbell+cfrg@mumble.net> Thu, 28 July 2022 19:47 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 CF510C15C51F for <cfrg@ietfa.amsl.com>; Thu, 28 Jul 2022 12:47:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.908
X-Spam-Level:
X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Kx8RH1rYurt for <cfrg@ietfa.amsl.com>; Thu, 28 Jul 2022 12:47:05 -0700 (PDT)
Received: from jupiter.mumble.net (jupiter.mumble.net [74.50.56.165]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 225BAC15C520 for <cfrg@irtf.org>; Thu, 28 Jul 2022 12:47:04 -0700 (PDT)
Received: by jupiter.mumble.net (Postfix, from userid 1014) id 7495260842; Thu, 28 Jul 2022 19:47:03 +0000 (UTC)
From: Taylor R Campbell <campbell+cfrg@mumble.net>
To: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
CC: "Crockett, Eric" <ericcro=40amazon.com@dmarc.ietf.org>, Martin Thomson <mt@lowentropy.net>, cfrg@irtf.org
In-reply-to: <5755C7A7-3073-41E2-89D2-44E0439743B8@ll.mit.edu> (uri@ll.mit.edu)
Date: Thu, 28 Jul 2022 19:46:58 +0000
Sender: Taylor R Campbell <campbell@mumble.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-Id: <20220728194703.7495260842@jupiter.mumble.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/MN7L1ZNKlFOuwec1bVrMT8PcudQ>
Subject: Re: [CFRG] Call for adoption for draft-denis-aegis-aead
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.39
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: Thu, 28 Jul 2022 19:47:09 -0000

> Date: Thu, 28 Jul 2022 19:15:23 +0000
> From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
> 
> > > From the draft:
> > >
> > > With AEGIS-256, random nonces can be used with no practical limits.
> >
> > We have use cases where we would like to encrypt >>>2^32 messages
> > with random nonces. GCM limits us to 2^32 messages with random IVs,
> > and it's not always possible to use deterministic IVs. Even when
> > it _is_ possible to use deterministic IVs, we sometimes would like
> > to encrypt >>2^64 messages with the same key. So having an AEAD scheme
> > which supports a practically-unbounded number of messages per key would be useful.
> 
> As I said before, my main problem with AEGIS is that nonce
> misuse/reuse breaks it.
> 
> With that in mind, I think that AEGIS is better than AES-GCM, but
> worse than an "ideal" AEAD that I'd like to see standardized and
> widely deployed.

Won't claim it's ideal, but ChaCha-Daence:

(a) supports a practically-unbounded number of messages per key[1];
(b) falls back to deterministic authenticated encryption security like
    AES-SIV if you don't have unique per-message numbers or if your
    RNG/counter goes wrong;
(c) can take advantage of public or secret message numbers, whether
    deterministic or random;
(d) does not require a randomized nonce like AES-GCM-SIV does for
    nonce-misuse-resistance;
(e) has a simpler interface, DAE (key,ad,message), than nonce-based
    AEAD (key,nonce,ad,message); and
(f) is built out of the same components as ChaCha/Poly1305 so it only
    takes a few lines of code with those components to implement it,
    so it's cheap to drop into applications that already use libraries
    with ChaCha and Poly1305 today -- no assembly (code) required.

Details and security theorem: https://eprint.iacr.org/2020/067

[1] Table of advantage bounds on p. 5 of the manuscript is generated
    by https://github.com/riastradh/daence/blob/master/adv.py, with
    references there to the best advantage bounds in the literature on
    AES-GCM, AES-GCM-SIV, AES-SIV, and ChaCha/Poly1305 security.