Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt

Yoav Nir <> Mon, 13 October 2014 11:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 85BAE1A212A for <>; Mon, 13 Oct 2014 04:32:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Oe3eNpIn-iof for <>; Mon, 13 Oct 2014 04:32:27 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 218571A3B9C for <>; Mon, 13 Oct 2014 04:32:26 -0700 (PDT)
Received: by with SMTP id fb4so7128497wid.16 for <>; Mon, 13 Oct 2014 04:32:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=XGbFoFmXVGLFts7OxRiXB74ryAVkrKQiPqETNhfOvRo=; b=0G+RsDEoymT9EXjDDuQfC/AhiBOg0NCKS/X6MU4Wrj/MUOq9j7+z/FlDq7Fp/sEDnF MC3bYPEoZqLSPJvcjJ++WGjLHwY4CPxEUpq9gMt3R5NBZRK6rPSSAXUlWxcm74bDDkC5 jsIAzZtuKldpn+N8Z+7Cyu5vfyd13j1jld9K4BqWLSstjixor/UAsEX/nFFWaq9G3352 V3QH9jiAdzdbbij7oz02oAHOA6BkzWa0TF1QquxtBM8uLUFl453du64lIj9LupKAI6ev 0MiU4Wllwx3lwRtEVCq8yVD6Y6dmmqvNY+dyvoupTi8g6M2Yx5aAL4mZeK0Q7agJCqHd 7yZg==
X-Received: by with SMTP id 8mr2515268wjq.85.1413199945804; Mon, 13 Oct 2014 04:32:25 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id lp8sm11858141wic.17.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Oct 2014 04:32:25 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_329381CE-3319-4055-A3DE-027148CF9560"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Mon, 13 Oct 2014 14:32:23 +0300
Message-Id: <>
References: <>
To: "" <>
X-Mailer: Apple Mail (2.1878.6)
Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Oct 2014 11:32:29 -0000

On Oct 2, 2014, at 3:45 PM, Alexey Melnikov <> wrote:

> The authors of "ChaCha20 and Poly1305 for IETF protocols", draft-irtf-cfrg-chacha20-poly1305-01.txt believe the draft is ready for a RGLC.
> This starts a two week research group last call, to end on 17 Oct 2014.
> The draft is available at
> Please do comment on the list, indicating whether you believe this draft is ready for publication. Please send your comments, indication of support for the publication or objections to the publication to the mailing list or directly to the RG chairs (
> Alexey,
> As a co-chair.


I haven’t submitted anything yet, but I’ve made a few changes to my local copy:
I’ve added the AEAD parameters from RFC 5116.
I’ve added the sentence suggested by Dan Harkins about combining several chunks of associated data (pretty much passing the responsibility for assembly/reassembly to the application)
I’ve changed the worked example for quarter-round, as suggested by Sean Parkinson (chose an example with the rotate-left amount not 16, because a rotate-left of 16 bits is similar to rotate-right of 16 bits)
I’ve added pseudo-code “implementations” to some of the algorithms, as suggested by Sean Parkinson

Things I didn’t do:
I did not change the counter/nonce split back to 64/64 as James Cloos suggested, because (a) that’s against a SHOULD in RFC 5116, and (b) it’s useful for multi-sender protocols, and (c) we had consensus for the change, and I don’t think we have consensus for the change back.
I did not switch to XChaCha as suggested by David Leon Gil
I did not incorporate the test vectors suggested by David because (a) they depend on suggested changes to hot the counter/nonce split, and (b) it might be addressed by limiting the amount of data that is allowed to be encrypted, which is in the draft (unless I totally misunderstood the suggestion)

For the (unpublished) draft with the changes, see:
 - TXT version:
 - HTML-ized version: