Re: [Cfrg] ChaCha20 and Poly1305 for IPsec

Yoav Nir <synp71@live.com> Tue, 21 January 2014 21:25 UTC

Return-Path: <synp71@live.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052ED1A0263 for <cfrg@ietfa.amsl.com>; Tue, 21 Jan 2014 13:25:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 vZkO9op3rFik for <cfrg@ietfa.amsl.com>; Tue, 21 Jan 2014 13:25:16 -0800 (PST)
Received: from blu0-omc1-s27.blu0.hotmail.com (blu0-omc1-s27.blu0.hotmail.com [65.55.116.38]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA2C1A0340 for <cfrg@irtf.org>; Tue, 21 Jan 2014 13:25:16 -0800 (PST)
Received: from BLU0-SMTP180 ([65.55.116.8]) by blu0-omc1-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Jan 2014 13:25:15 -0800
X-TMN: [gUjv4p5U+JvqAzFrv8m0ikoQWY0NB7KQ]
X-Originating-Email: [synp71@live.com]
Message-ID: <BLU0-SMTP1803BBEDFAF18F164D98C0FB1A40@phx.gbl>
Received: from ynir-MBA.local ([84.109.50.18]) by BLU0-SMTP180.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Jan 2014 13:25:13 -0800
Date: Tue, 21 Jan 2014 23:25:07 +0200
From: Yoav Nir <synp71@live.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Watson Ladd <watsonbladd@gmail.com>
References: <180998C7-B6E5-489E-9C79-80D9CAC0DE68@checkpoint.com> <CAL9PXLy9hrq+i_neP96FbTJRvRLbLEXnMYdBdwSeHunFAwF+jQ@mail.gmail.com> <A867BB8E-4556-44B1-A0AF-16771626BF5C@checkpoint.com> <52CB358D.3050603@cisco.com> <A6BDE08D-1F7D-4813-A9C4-61AF8C14412B@checkpoint.com> <52CB482D.6090807@cisco.com> <09031D92-9A14-4CF0-A000-123E71D4F784@checkpoint.com> <3861F1D4-B412-42BE-AE6C-FF5DE213854C@checkpoint.com> <CAL9PXLzgo5a2dk0JM-kWvawPhO1arpurcYSuqcffTWGdrCGY7A@mail.gmail.com> <301290EC-B31A-4B83-9F29-D00469EC6CB8@checkpoint.com> <CACsn0cmS9yY4+WcJH6o3QMdXhf+wr5dhLvibsRUdFu0aY-dRmg@mail.gmail.com>
In-Reply-To: <CACsn0cmS9yY4+WcJH6o3QMdXhf+wr5dhLvibsRUdFu0aY-dRmg@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010604030309070903040905"
X-OriginalArrivalTime: 21 Jan 2014 21:25:13.0899 (UTC) FILETIME=[45ACEFB0:01CF16EF]
Cc: David McGrew <mcgrew@cisco.com>, cfrg@irtf.org, Adam Langley <agl@google.com>
Subject: Re: [Cfrg] ChaCha20 and Poly1305 for IPsec
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jan 2014 21:25:18 -0000

On 21/1/14 11:05 PM, Watson Ladd wrote:
>
> >
> > I've posted this to ipsec as well. They said that we need a better 
> normative reference for the functions. DJB's papers discuss security 
> properties and link to source code, but don't have a good definition.
> >
>
> Are you reading the same paper I am? He defines Salsa and ChaCha in 
> terms of applying a well defined quarter round function to the rows 
> and diagonals of a 4x4 matrix.
>

I'm reading this one:
http://cr.yp.to/chacha/chacha-20080128.pdf

It's mixing description, comparison with Salsa20, security analysis and 
performance data. That's fine for a paper. I could probably write an 
implementation based on that, but I would have very little confidence 
that it is correct.

For RFCs, we like to have a clear document that is as short as possible, 
and has a very clear definition, and a few test vectors so an 
implementer can check their code.

I'm not totally convinced by Yaron's response ([1]), but I'd rather not 
be forced to repeat much of the algorithm in my draft, as Adam did in 
sections 3 & 4 of [2].

Yoav

[1] http://www.ietf.org/mail-archive/web/ipsec/current/msg08929.html
[2] http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04