Re: [Cfrg] ChaCha20 and Poly1305 for IPsec

Watson Ladd <watsonbladd@gmail.com> Tue, 07 January 2014 00:33 UTC

Return-Path: <watsonbladd@gmail.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 4C4881ADBD2 for <cfrg@ietfa.amsl.com>; Mon, 6 Jan 2014 16:33:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] 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 wSKIVB9-4bwJ for <cfrg@ietfa.amsl.com>; Mon, 6 Jan 2014 16:33:44 -0800 (PST)
Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0F21A1AD986 for <cfrg@irtf.org>; Mon, 6 Jan 2014 16:33:43 -0800 (PST)
Received: by mail-we0-f177.google.com with SMTP id u56so16533946wes.36 for <cfrg@irtf.org>; Mon, 06 Jan 2014 16:33:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6UTMjTfXcBsPAKhMxXJfsGJR2A9YypPnrKSOwKS4tGc=; b=y7rNlM2o9n/2D5RKiTzdX6g7bWkb/I+7TBW7vF6SA9TD/fGjJfeqsS+341TgrF9zuM NSHavzSRe6vdGYlYsKbFNNRtBFv2UjQkAF8QWBHt2xf0S1qPnYK81mhF2imAMRpkKRfZ bl27VM5GrBej/avaF4w10E8wJeHu3uIOAOnvt44Y22IThl3a5WzEjd7w6/YGeScSaahK rnUJkBxdZ4YQMd50sDVKYV3WIoeUCl9dxoEn3QOEnezJyUPlOVqmTEIWu6MBCZ824LJv tgHvZjqX5Zpc7XrelfF8mU5ZMwSNt1Bu78cfgq3bn+HhOAqtPgQ4X7wogpIwPlgs5Dc4 PCtA==
MIME-Version: 1.0
X-Received: by 10.194.61.3 with SMTP id l3mr539131wjr.18.1389054814731; Mon, 06 Jan 2014 16:33:34 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Mon, 6 Jan 2014 16:33:34 -0800 (PST)
In-Reply-To: <52CB482D.6090807@cisco.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>
Date: Mon, 6 Jan 2014 16:33:34 -0800
Message-ID: <CACsn0cmTyxtFnFdGQ=oO+UpHFK1TmBFHBwE5SVz1oDnHGZ2GwA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: David McGrew <mcgrew@cisco.com>
Content-Type: text/plain; charset=UTF-8
Cc: "cfrg@irtf.org" <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, 07 Jan 2014 00:33:47 -0000

On Mon, Jan 6, 2014 at 4:19 PM, David McGrew <mcgrew@cisco.com>; wrote:
> Hi Yoav,
>
>
> On 01/06/2014 06:43 PM, Yoav Nir wrote:
>>
>> On Jan 7, 2014, at 1:00 AM, David McGrew <mcgrew@cisco.com>;
>>   wrote:
>>
>>> Hi Yoav,
>>>
>>> On 01/06/2014 05:23 PM, Yoav Nir wrote:
>>>>
>>>> Thanks. Proposing this seems so obvious, that I thought I must be
>>>> missing something that makes it unsuitable.
>>>>
>>>> On Jan 6, 2014, at 8:05 PM, Adam Langley <agl@google.com>; wrote:
>>>>
>>>>> On Sun, Jan 5, 2014 at 11:18 AM, Yoav Nir <ynir@checkpoint.com>; wrote:
>>>>>>
>>>>>> Unlike RC4, ChaCha20 has a 64-bit nonce, so different packets could
>>>>>> use different keystreams, much like block ciphers in counter mode. Unlike
>>>>>> 3DES, ChaCha20 has performance that is close to that of AES.
>>>>>>
>>>>>> So my question is whether there is any reason not to use ChaCha20
>>>>>> (with or without the AEAD construction from Adam's draft) for IKE and/or
>>>>>> IPsec. Could this be the standby algorithm that we have been looking for?
>>>>>
>>>>> I don't know of any problems with this. If IPsec has the concept of a
>>>>> counter than can be used as an nonce then I think the AEAD
>>>>> construction would be fine, as is.
>>>>
>>>> IPsec has a 32- or 64-bit packet counter, but for some reason it has
>>>> never been used as a nonce. Both AES-CTR and AES-GCM have explicit 64-bit
>>>> IVs in IPsec, so I think a ChaCha implementation should do the same - have
>>>> an explicit IV that's used as a nonce, with a MUST requirement for
>>>> uniqueness of IV/key combination.
>>>
>>> the reason that the ESP sequence number isn't used as a cryptographic
>>> nonce is that it was not regarded as reliable enough.   That is, the ESP
>>> standard does not insist that the sequence number never wrap, and many
>>> implementations are not careful about maintaining the uniqueness of the
>>> sequence number.  This situation is not ideal, but it does seem to be the
>>> case.
>>
>> I agree that the text could use some more RFC2119 language, but allowing
>> the sequence to wrap is not allowed:
>>
>>                                                If anti-replay is enabled
>>     (the default), the transmitted Sequence Number must never be allowed
>>     to cycle.  Thus, the sender's counter and the receiver's counter MUST
>>     be reset (by establishing a new SA and thus a new key) prior to the
>>     transmission of the 2^32nd packet on an SA.
>>
>>>>> If one needs to pick the nonces
>>>>> randomly, however, then a 64-bit space is too small and XChaCha (which
>>>>> has a 192-bit nonce) would be more suitable.
>>>>
>>>> It would work, but IPsec requires re-keying when the 32-bit or 64-bit
>>>> counter reaches 2^n-1, so that seems like overkill.
>>>
>>> Agreed that a 192-bit nonce sounds a bit big.
>>>
>>> ESP supports multipoint security associations, in which case it is
>>> essential to coordinate nonces across all of the encrypters, to make sure
>>> that they are all distinct.   The requirements and a simple approach is
>>> outlined in rfc6054, and those requirements are followed in the latest
>>> version of the Group Domain of Interpretation rfc6407.  The nonce management
>>> is a bit ugly, but there is precedent for it.
>>>
>>> We could do a lot worse than ChaCha as a cipher.   An AEAD construction
>>> could be used in a way that mirrors GCM/CCM, though if I recall right, Adam
>>> defined an 8-byte nonce rather than a 12-byte nonce for the ChaCha AEAD
>>> algorithm, which makes it incompatible with almost all of the other AEAD
>>> algorithms (see Table 1 of draft-mcgrew-iv-gen-02).   A 12-byte nonce would
>>> enable ESP implementations to use the same nonce generation techniques,
>>> including rfc6407 ones.
>>
>> An 8-byte nonce is part of ChaCha.
>
>
>  - faceplam -  Yes, of course.
>
>
>> This is different from counter mode where the initial counter could be
>> anything up to block size. I don't claim to understand why ChaCha has a
>> 64-bit nonce and a 64-bit block counter instead of, say, a 96-bit nonce and
>> a 32-bit block counter (good for 256 GB - plenty for an IP packet). Would
>> ChaCha modified like that retain its security properties?
>
>
> I think so - I would be surprised if it didn't retain its security
> properties.   But it might be best to avoid tweaking the design.
>
>
>>
>>> My biggest concern with ChaCha is: will it have the global credibility
>>> that we need?    If we think that it does, we should go about documenting
>>> the work that has been done analyzing it.  The record of the analysis will
>>> become extremely important once the cipher gets picked up by the
>>> semi-technical press and the user community.
>>
>> That sounds like a good task for CFRG. As some have mentioned in previous
>> threads, we can't trust NIST for all our crypto needs.
>
>
> That makes sense to me, but I would also much like to hear other opinions.

I don't think anything new has really been found, despite a lot of
kicking the tires
with BLAKE and Salsa20. However, DJB did use XSalsa20 instead of
XChaCha20 (a hypothetical
longer nonce variant) in NaCl, so maybe the performance benefit is
gone with new CPUs?

As for the nonce/block counter size adjustment, 96 bits still can't be
picked at random, but
32 bit objects are occasionally encrypted. If I can fit in memory, I
should be able to deal with it
is the philosophy. But for the security of ChaCha it doesn't matter:
the nonce and block counter
are treated alike, and both are public.
Sincerely,
Watson

>
> David
>
>
>> This is not that they're evil, but more in that they're reluctant to
>> endorse something that didn't originate with them (GCM was a fluke). So we
>> have to rely on other sources.
>>
>>> Since so much of ESP is point to point and works at a high data rate, it
>>> makes sense to think about counter-based nonces and throughput-optimized
>>> algorithms, like ChaCha.   Algorithms that are misuse-resistant would be
>>> useful in scenarios other than point-to-point ones, and in my opinion are
>>> also worth considering as future work for ESP.
>>>
>>> David
>>
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> http://www.irtf.org/mailman/listinfo/cfrg
>> .
>>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin