Re: [CFRG] XChacha20 counter size

Loup Vaillant-David <> Sat, 26 December 2020 00:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 50E2B3A0E6C for <>; Fri, 25 Dec 2020 16:22:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tDs8bE2ZvJWp for <>; Fri, 25 Dec 2020 16:22:20 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 36CCA3A0E6B for <>; Fri, 25 Dec 2020 16:22:19 -0800 (PST)
Received: from grey-fade ( []) (Authenticated sender: by (Postfix) with ESMTPSA id CB9BD240005; Sat, 26 Dec 2020 00:22:13 +0000 (UTC)
Message-ID: <>
From: Loup Vaillant-David <>
To: Taylor R Campbell <>
Date: Sat, 26 Dec 2020 01:22:12 +0100
In-Reply-To: <>
References: <>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [CFRG] XChacha20 counter size
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 26 Dec 2020 00:22:22 -0000

> An application that accepts 256 GiB messages is an application that's
> already prepared to shoot itself in the foot.  Individual messages
> shouldn't be that long -- especially messages transmitted over the
> internet.  You should break large messages into pieces of reasonable
> size for separate authenticated encryption.

I'm aware. And if I were to design even a file encryption system, I
would break up that file in chunks so that the application can process
each chunk with very little RAM, and commit the plaintext to disk only
when the chunk is only fully processed.

Yes, properly designed applications would never allow that. My problem
here is *improperly* designed applications. I don't want to see them
fail too badly.

> This is also relevant for authenticators based on universal hashes
> like AES-GCM and ChaCha/Poly1305, whose security depends linearly on
> the _maximum_ message length (not just the total amount of data):
> Accept a single 256 GiB message, and the number of messages you can
> safely handle -- even if all the others are tiny -- dramatically
> drops compared to an application limited to 2^14 bytes per message
> like TLS.

Oh. I didn't know. I'll study those limits in more detail, thanks.

> > - This is a departure from existing implementations. XSalsa20 from
> >   NaCl uses a 64-bit counter. XChacha20 in Libsodium also uses a 
> >   64-bit counter. In general, all XChacha20 implementations I know 
> >   of use a 64-bit counter.
> Many Salsa20 and ChaCha implementations, including a number in
> SUPERCOP and the implementations named amd64-xmm5 and amd64-xmm6
> published by the designer (, silently
> repeat the key stream if you try to use them for more than 2^32
> blocks.