Re: [Cfrg] ChaCha20 and Poly1305 for IPsec
David McGrew <mcgrew@cisco.com> Mon, 06 January 2014 23:00 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 925881AE2BB for <cfrg@ietfa.amsl.com>; Mon, 6 Jan 2014 15:00:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.039
X-Spam-Level:
X-Spam-Status: No, score=-10.039 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.538, 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 rZXXBlUxFUaZ for <cfrg@ietfa.amsl.com>; Mon, 6 Jan 2014 15:00:39 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id AA8941AE2BC for <cfrg@irtf.org>; Mon, 6 Jan 2014 15:00:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3735; q=dns/txt; s=iport; t=1389049231; x=1390258831; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ZHbLUdLPPu9cbVUV1V24QXeeAPQgd1CGDocjur8aFks=; b=bPc6LOCGaPaFJKExRgdmYNQ7zQdK0+C8Zd56fCIxW+AAWqXYwEfO1RtC 0qrB5hlNqcBwJbOrxWHDZj1DYqcjv/AsFHAbtQSpqogwrHp0vzU9UZAoa 5st55/Tou3rAnOCg06a8RBrxuGoq0bEQ1O9AUv8KhbNoGuUAcsK4xpSG3 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkMFAHM0y1KtJXG8/2dsb2JhbABYgws4uiKBDhZ0giUBAQEDAQEBATU2CgEQCw4KCRYPCQMCAQIBFTAGDQEFAgIFC4doCA3DYxeMbSiBegeENwSJQ45UhkWLUINLHg
X-IronPort-AV: E=Sophos;i="4.95,614,1384300800"; d="scan'208";a="10927721"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-5.cisco.com with ESMTP; 06 Jan 2014 23:00:29 +0000
Received: from [10.0.2.15] (rtp-mcgrew-8913.cisco.com [10.117.10.228]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s06N0SVe031043; Mon, 6 Jan 2014 23:00:28 GMT
Message-ID: <52CB358D.3050603@cisco.com>
Date: Mon, 06 Jan 2014 18:00:29 -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: Yoav Nir <ynir@checkpoint.com>
References: <180998C7-B6E5-489E-9C79-80D9CAC0DE68@checkpoint.com> <CAL9PXLy9hrq+i_neP96FbTJRvRLbLEXnMYdBdwSeHunFAwF+jQ@mail.gmail.com> <A867BB8E-4556-44B1-A0AF-16771626BF5C@checkpoint.com>
In-Reply-To: <A867BB8E-4556-44B1-A0AF-16771626BF5C@checkpoint.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Mon, 06 Jan 2014 23:00:41 -0000
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. > >> 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. 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. 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 > > Thanks again > > Yoav > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg >
- [Cfrg] ChaCha20 and Poly1305 for IPsec Yoav Nir
- Re: [Cfrg] ChaCha20 and Poly1305 for IPsec Yoav Nir
- Re: [Cfrg] ChaCha20 and Poly1305 for IPsec David McGrew
- Re: [Cfrg] ChaCha20 and Poly1305 for IPsec Yoav Nir
- Re: [Cfrg] ChaCha20 and Poly1305 for IPsec Ted Krovetz
- Re: [Cfrg] ChaCha20 and Poly1305 for IPsec David McGrew
- Re: [Cfrg] ChaCha20 and Poly1305 for IPsec Watson Ladd
- Re: [Cfrg] ChaCha20 and Poly1305 for IPsec CodesInChaos
- Re: [Cfrg] ChaCha20 and Poly1305 for IPsec Yoav Nir
- Re: [Cfrg] ChaCha20 and Poly1305 for IPsec Yoav Nir
- Re: [Cfrg] ChaCha20 and Poly1305 for IPsec Watson Ladd
- Re: [Cfrg] ChaCha20 and Poly1305 for IPsec Yoav Nir
- Re: [Cfrg] ChaCha20 and Poly1305 for IPsec Yoav Nir
- Re: [Cfrg] ChaCha20 and Poly1305 for IPsec Yoav Nir
- [Cfrg] questions on performance and side channel … David McGrew
- Re: [Cfrg] ChaCha20 and Poly1305 for IPsec David McGrew
- Re: [Cfrg] ChaCha20 and Poly1305 for IPsec David McGrew
- Re: [Cfrg] questions on performance and side chan… Robert Ransom
- Re: [Cfrg] questions on performance and side chan… David McGrew
- Re: [Cfrg] questions on performance and side chan… David McGrew
- Re: [Cfrg] questions on performance and side chan… Yoav Nir
- Re: [Cfrg] questions on performance and side chan… David McGrew