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

Taylor R Campbell <campbell+cfrg@mumble.net> Sat, 26 January 2019 17:15 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 D4FE5130F3A for <cfrg@ietfa.amsl.com>; Sat, 26 Jan 2019 09:15:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSkqln11zd6v for <cfrg@ietfa.amsl.com>; Sat, 26 Jan 2019 09:15:39 -0800 (PST)
Received: from jupiter.mumble.net (jupiter.mumble.net [74.50.56.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 831BF130E5F for <cfrg@irtf.org>; Sat, 26 Jan 2019 09:15:39 -0800 (PST)
Received: by jupiter.mumble.net (Postfix, from userid 1014) id EE54D60C39; Sat, 26 Jan 2019 17:15:37 +0000 (UTC)
From: Taylor R Campbell <campbell+cfrg@mumble.net>
To: noloader@gmail.com
CC: cfrg@irtf.org
In-reply-to: <CAH8yC8=0Y6qK0dHauib8fM-ybGozJJRA7b5vKnu8-dPVxwytLQ@mail.gmail.com> (noloader@gmail.com)
Date: Sat, 26 Jan 2019 17:15:37 +0000
Sender: Taylor R Campbell <campbell@mumble.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20190126171537.EE54D60C39@jupiter.mumble.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/7uOL4DI37AVa8gm-R0AM9jhlPfc>
Subject: Re: [Cfrg] How to handle block counter wrap in IETF's ChaCha algorithm?
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
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: Sat, 26 Jan 2019 17:15:47 -0000

> Date: Fri, 25 Jan 2019 22:20:38 -0500
> From: Jeffrey Walton <noloader@gmail.com>;
> 
> 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.