Re: [Cfrg] How to handle block counter wrap in IETF's ChaCha algorithm?

Taylor R Campbell <> Sat, 26 January 2019 17:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D4FE5130F3A for <>; Sat, 26 Jan 2019 09:15:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gSkqln11zd6v for <>; Sat, 26 Jan 2019 09:15:39 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 831BF130E5F for <>; Sat, 26 Jan 2019 09:15:39 -0800 (PST)
Received: by (Postfix, from userid 1014) id EE54D60C39; Sat, 26 Jan 2019 17:15:37 +0000 (UTC)
From: Taylor R Campbell <>
In-reply-to: <> (
Date: Sat, 26 Jan 2019 17:15:37 +0000
Sender: Taylor R Campbell <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <>
Archived-At: <>
Subject: Re: [Cfrg] How to handle block counter wrap in IETF's ChaCha algorithm?
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 Jan 2019 17:15:47 -0000

> Date: Fri, 25 Jan 2019 22:20:38 -0500
> From: Jeffrey Walton <>
> My question is, what should happen when the block counter wraps?

You should design your _protocol_ so that

(a) it starts at block counter 0,
(b) it is limited to packets 2^32 blocks long.

If you want to handle larger messages, break them up into multiple
packets with distinct nonces.

The largest packet you are willing to _authenticate_ (you are using it
together with an authenticator like Poly1305 in your protocol, right?)
is an upper bound on the amount of your memory an adversary can waste
in a DoS attack before you can drop it on the floor.

If, on the other hand, you're confined to implementing an existing
protocol, you should implement whatever that protocol prescribes --
and write automatic tests that enshrine the behaviour.

But most protocols don't handle messages that large, partly because
they pose trivial DoS risks.  For example, in TLS, packets (`records')
are limited to 2^14 octets -- far smaller than the 2^32-block limit.

Unless you have an application that actually starts the block counter
in the middle of a message or actually uses >4 GB messages -- if
you're really concerned it might make a difference, make block counter
overflow a fail noisily.