Re: [Cfrg] ChaCha20 and Poly1305 for IPsec

David McGrew <mcgrew@cisco.com> Thu, 23 January 2014 15:01 UTC

Return-Path: <mcgrew@cisco.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 0C6EF1A0006 for <cfrg@ietfa.amsl.com>; Thu, 23 Jan 2014 07:01:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.036
X-Spam-Level:
X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 tukObeMv1Ny4 for <cfrg@ietfa.amsl.com>; Thu, 23 Jan 2014 07:01:45 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 69DFC1A0005 for <cfrg@irtf.org>; Thu, 23 Jan 2014 07:01:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1679; q=dns/txt; s=iport; t=1390489305; x=1391698905; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=H+30UrHYQAMy9gBeFkv87iBhqWYh4PonG0Ef7uleVR4=; b=eWg7R6qrI3OamAO6MvrLy5JUp8207P6AESXGzFgSCm9ovPO1CUj1+bTR /3s5WGSKqCTYsGRDnMZZX5puKq6vsUuD13qjbBHFvYp1GK4wjQse/2Kdp 0UqZHTvT7rNC7ex0wR8av3eCiw/Ho0jVxWvxuqgNsZE58/aajaYQH2cr/ 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsFAI8t4VKQ/khN/2dsb2JhbABbgwyEDLh1gRAWdIIlAQEBAwEjFUABBQsLDgoCAgUWCwICCQMCAQIBRQYNAQUCAod5CKlRnBsXgSmNVweCb4FJAQOJSI5bhkeLUYNLHg
X-IronPort-AV: E=Sophos;i="4.95,706,1384300800"; d="scan'208";a="3406711"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 23 Jan 2014 15:01:43 +0000
Received: from [10.0.2.15] ([10.148.144.89]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0NF1h7d007377; Thu, 23 Jan 2014 15:01:43 GMT
Message-ID: <52E12ED7.6070405@cisco.com>
Date: Thu, 23 Jan 2014 10:01:43 -0500
From: David McGrew <mcgrew@cisco.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130922 Icedove/17.0.9
MIME-Version: 1.0
To: Adam Langley <agl@google.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> <8CE7853F-0CA3-4295-89D4-CFAF1887C876@checkpoint.com> <CAL9PXLzyiT9dNiNdeA42oe+o_sqL27MmJ1L0HVuM7ixYA-W2Bg@mail.gmail.com>
In-Reply-To: <CAL9PXLzyiT9dNiNdeA42oe+o_sqL27MmJ1L0HVuM7ixYA-W2Bg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
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: Thu, 23 Jan 2014 15:01:47 -0000

On 01/21/2014 05:08 PM, Adam Langley wrote:
> On Tue, Jan 21, 2014 at 4:53 PM, Yoav Nir <ynir@checkpoint.com> wrote:
>> Looking into GCM, I see two other things:
>>   1. The lengths there are big-endian ("...a 64-bit string containing the nonnegative integer describing the number of bits in its argument, with the least significant bit on the right.")
>>   2. The lengths there are the number of bits, not bytes.
>>
>> Big-endian always seemed to me to be more "natural" because most binary protocols transmit numbers that way, but I don't think there's any reason to count bits, is there?
> There might be an implementation of GCM that supports bit lengths that
> are not a multiple of 8, but I'm not aware of it.

I'm not aware of it either, if it exists.

With GCM, we took this strategy: make the inputs and outputs octet 
strings, since that is what really matters in the real world, but then 
use the number of bits in the computation of the authentication tag 
rather than the number of bytes, so that it would be possible for 
someone else to define a bit-oriented version of the algorithm if they 
really need to.

> I think little-endian makes more sense in a ChaCha20-Poly1305 AEAD
> because everything else in the AEAD (ChaCha and Poly1305) is handled
> as little-endian.
>
> (I've also done enough implementations of the arithmetic that I find
> little-endian to be preferable in general, but that might just be
> brain damage.)
>

For what it is worth, little endian has a legitimate advantage in that 
enables better pipelining of multiplications.   But I think this is a 
six-or-half-dozen issue.

David

> Cheers
>
> AGL
>