Re: [Cfrg] ChaCha20 and Poly1305 for IPsec

Yoav Nir <> Mon, 06 January 2014 22:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 85F9F1AE292 for <>; Mon, 6 Jan 2014 14:23:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.439
X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bD970NksVbNT for <>; Mon, 6 Jan 2014 14:23:43 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 438331AE27E for <>; Mon, 6 Jan 2014 14:23:43 -0800 (PST)
Received: from ([]) by (8.13.8/8.13.8) with ESMTP id s06MNWlF032223; Tue, 7 Jan 2014 00:23:32 +0200
X-CheckPoint: {52CB27C5-2-1B221DC2-1FFFF}
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Tue, 7 Jan 2014 00:23:31 +0200
From: Yoav Nir <>
To: Adam Langley <>
Thread-Topic: ChaCha20 and Poly1305 for IPsec
Thread-Index: AQHPCjHEk17DdD0mQkqxUhltboUzx5p33c2AgABIH4A=
Date: Mon, 6 Jan 2014 22:23:31 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [Cfrg] ChaCha20 and Poly1305 for IPsec
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Jan 2014 22:23:45 -0000

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 <> wrote:

> On Sun, Jan 5, 2014 at 11:18 AM, Yoav Nir <> 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.

> 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.

Thanks again