Re: [TLS] Comments on draft-nir-cfrg-chacha20-poly1305-02

nisse@lysator.liu.se (Niels Möller ) Fri, 06 February 2015 19:50 UTC

Return-Path: <nisse@lysator.liu.se>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEDF81A1BC7 for <tls@ietfa.amsl.com>; Fri, 6 Feb 2015 11:50:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.261
X-Spam-Level:
X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 DtzsdZu2l5oW for <tls@ietfa.amsl.com>; Fri, 6 Feb 2015 11:50:35 -0800 (PST)
Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A7371A87D0 for <tls@ietf.org>; Fri, 6 Feb 2015 11:49:41 -0800 (PST)
Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id C01B64002C; Fri, 6 Feb 2015 20:49:39 +0100 (CET)
Received: from bacon.lysator.liu.se (vindbrygga.lysator.liu.se [IPv6:2001:6b0:17:f0a0::de]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPS id 673D640010; Fri, 6 Feb 2015 20:49:39 +0100 (CET)
Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id t16Jndb0027342; Fri, 6 Feb 2015 20:49:39 +0100 (MET)
Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id t16Jncaa027341; Fri, 6 Feb 2015 20:49:38 +0100 (MET)
X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f
From: nisse@lysator.liu.se
To: Adam Langley <agl@google.com>
References: <nnha83nwy9.fsf@bacon.lysator.liu.se> <CAL9PXLyWhqSdG5YRyrOprW5wgCYCwHn7_a=R2sb+mN-irkMYbA@mail.gmail.com> <nniopgn2sr.fsf@bacon.lysator.liu.se> <CAMfhd9VsetxqazXdmDPTDCJJqC5jNr1LVC-qsgPM9RRSBXSTqA@mail.gmail.com> <nnk2zv3zbo.fsf@bacon.lysator.liu.se> <CAL9PXLx7O-qRQcsDVcTTjTmt7Uk+DTLaMRwST=cZj30OSrBbog@mail.gmail.com>
Date: Fri, 06 Feb 2015 20:49:38 +0100
In-Reply-To: <CAL9PXLx7O-qRQcsDVcTTjTmt7Uk+DTLaMRwST=cZj30OSrBbog@mail.gmail.com> (Adam Langley's message of "Fri, 6 Feb 2015 10:15:21 -0800")
Message-ID: <nn386i4y7h.fsf@bacon.lysator.liu.se>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/PfnYE9w4Ai8kCcyz9UKuV21Mk1s>
Cc: Adam Langley <agl@imperialviolet.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Comments on draft-nir-cfrg-chacha20-poly1305-02
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2015 19:50:37 -0000

Adam Langley <agl@google.com> writes:

>> In section 2.4.2, the test vector for the chacha20 cipher, I think it
>> would be good to have an example with initial counter = 0. I think
>> that's going to be the typical case when using chacha as cipher only.
>
> The draft defines an AEAD so I think it's ok that the examples are
> focused on that.

Now I see that there are additional test vectors in appendix A.2, that's
nice, sorry I missed that initially. But I think it would be valuable to
add a test vector with a non-zero nonce, say 01 02 03 04 05 06 07 08 09
0a 0b 0c, a non-zero key, and a zero initial counter, and two blocks of
data. That should test for most of the formatting pitfalls with a single
test-case for the most basic encryption interface, without
random-access-features.

>> In section 2.8.2, the nonce is given in two pieces, an "IV" and a
>> "32-bit fixed common part". It's not crystal clear how to put then
>> together. Please also write out the complete 12-byte nonce explicitly.
>
> It does seem that this section might be a little IPSec focused. The
> nonce is called an nonce elsewhere in the draft, but is given as an
> "IV" and "fixed-common part" here, but those terms are never used
> elsewhere. Possibly they should be merged and called an nonce,
> although I'm sure that Yoav will decide what's best here.

I think that division can also be found in RFC 5116, but I think it's
important that it's crystal clear what the inputs are. It's fine to list
both the pieces and the combined 12-byte nonce, if you think the
division is important.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.