Re: [CFRG] XChacha20 counter size

Loup Vaillant-David <> Sat, 26 December 2020 12:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 28B103A102A for <>; Sat, 26 Dec 2020 04:03:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 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] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AdAYtInqgvmf for <>; Sat, 26 Dec 2020 04:03:21 -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 4350C3A102B for <>; Sat, 26 Dec 2020 04:03:20 -0800 (PST)
Received: from grey-fade (unknown []) (Authenticated sender: by (Postfix) with ESMTPSA id 31480240002; Sat, 26 Dec 2020 12:03:16 +0000 (UTC)
Message-ID: <>
From: Loup Vaillant-David <>
To: Scott Arciszewski <>, Filippo Valsorda <>
Date: Sat, 26 Dec 2020 13:03:04 +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 12:03:23 -0000

> As the author of the XChaCha RFC draft, I view making XChaCha20-
> Poly1305 incompatible with the IETF's ChaCha20-Poly1305 a non-goal.

Understand that my proposal *is* compatible.

On section 2.3.1 of your draft, you specify the following pseudocode:

    xchacha20_encrypt(key, nonce, plaintext, blk_ctr = 0):
        subkey = hchacha20(key, nonce[0:15])
        chacha20_nonce = "\x00\x00\x00\x00" + nonce[16:23]

        return chacha20_encrypt(subkey, chacha20_nonce,
                                plaintext, blk_ctr)

The only difference between that and Libsodium is what happens when the
message exceeds >256GiB. A use case that as far as I understand RFC
8439 does not define. Implementations have 3 realistic choices when
dealing with such undefined behaviour:

1. Wrap the counter back to zero, and trigger an insecure stream reuse.
   This is what happens when we naively implement XChacha20 on top of
RFC 8439. This would disclose the authentication key, one of the
worst vulnerability possible.

2. Panic, crash, or report an error. This is typical of misuse aware
   libraries. I have no problem with this behaviour. It's a bit
   limiting, but at least it's secure.

3. Increment the next word, currently occupied by the nonce. This is
   what naturally happens when we derive XChacha20 from DJB's Chacha20.
   As much as we may disapprove of gigantic messages, this one at least
   does not break all security, and is a nice alternative for libraries
   who cannot (or will not) report an error.

I don't want incompatibility with RFC 8439. All I'm asking here is that
we disallow (1), and allow (3).