Re: [quicwg/base-drafts] Simplify ChaCha20 interface (#2990)

Kazuho Oku <> Thu, 05 September 2019 21:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 38A38120B78 for <>; Thu, 5 Sep 2019 14:48:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pkBoNNzfid7N for <>; Thu, 5 Sep 2019 14:48:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7885212081C for <>; Thu, 5 Sep 2019 14:48:00 -0700 (PDT)
Date: Thu, 05 Sep 2019 14:47:59 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1567720079; bh=sdPLdVKOho2rM7JilH2bNq2dZ1Cf+hF679yQTVUpa7k=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=yzMFvB+47ihs4HGRJby7oD74oFNqpI9moYepKb3b1wokfx94HcCdDZOHWoFlvvDVG cUWjk/V4HZBUgcyXsvm9F30NVyBX5Rx1A/za6A802XbElo3CgqocPUwtURUo8ukrYY jK3AzOX4KcvRSXBceD3Z/jdQH4t6DwkMPRb4cJhs=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2990/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Simplify ChaCha20 interface (#2990)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d71828fb3cb3_48533f9f860cd9645142d5"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Sep 2019 21:48:12 -0000

kazuho commented on this pull request.

> @@ -1049,16 +1049,16 @@ function as defined in Section 2.4 of {{!CHACHA}}.  This uses a 256-bit key and
 16 bytes sampled from the packet protection output.
 The first 4 bytes of the sampled ciphertext are interpreted as a 32-bit number
-in little-endian order and are used as the block count.  The remaining 12 bytes
-are interpreted as three concatenated 32-bit numbers in little-endian order and
-used as the nonce.
+in little-endian order and are used as the block count; a ChaCha20
+implementation might instead take the 4 bytes as an opaque sequence of bytes.
+The remaining 12 bytes are used as the nonce.

While I like the idea of providing practical advice, I am a bit concerned of dropping the text that state the format of input in terms of specification language (in this case RFC 7539).

RFC 7539 assumes that the nonce to be three uint32 values. Is it possible to provide a formal definition without describing the interaction with that design? In practice, I think that the new text does not read good when the user is using a Chacha20 implementation (used on a big endian machine) that in fact takes uint32 values as inputs (rather than octets).

To reiterate, I think that it might be better preserve the existing text, at the same time "adding" implementation advice when using a Chacha20 function that takes octets as input.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: