Re: [Cfrg] ChaCha20 and Poly1305 for IPsec

Ted Krovetz <ted@krovetz.net> Mon, 06 January 2014 23:54 UTC

Return-Path: <ted@krovetz.net>
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 A25891AE33D for <cfrg@ietfa.amsl.com>; Mon, 6 Jan 2014 15:54:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] 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 ZGcpMoSqRy0Y for <cfrg@ietfa.amsl.com>; Mon, 6 Jan 2014 15:54:27 -0800 (PST)
Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE491AE337 for <cfrg@irtf.org>; Mon, 6 Jan 2014 15:54:27 -0800 (PST)
Received: by mail-pd0-f170.google.com with SMTP id g10so18739447pdj.15 for <cfrg@irtf.org>; Mon, 06 Jan 2014 15:54:19 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=xbHreAXkORKJ6DLXaGPNZC+GbpT/pTD+91YQc23plig=; b=gSwlpJX6ysfYfjixst8Je+iYCKzM2DtNDCl7Mb7dFPOqVMoZkxyAKPXuDur1bm2Bwy c7+oOv4/UDXXAjoJlmhiM938Jc805Qb2YkiaSoUI0lxc/tBzgBpAd1fkLtp4uDcjLWLS k4jKq2E1C34m9TvlHhuZYRf2g9+pUk++bdjxaJCWiHaYFaaT7C+AsVbPJznEgiZaEpSg TLv+emepl09/Irrt/ojGmjBgBvcVhOAvz/wthxB2ykv34H/3ATucjZJgmhcfRgl+aPKo +ypeJAZDgMT9tWwQ+3hQR08gqHB2VDvtPD9AztyYlW1RdPs67Nb2gpt3pgIJaSLxB5Zu KCfQ==
X-Gm-Message-State: ALoCoQl5LaONj2tj43ofjNvfBSTS3Q6A9gIuhyhLSCnQQ6q++p7OYtbMUNqqYNC/2xU1R65xUBOd
X-Received: by 10.69.18.234 with SMTP id gp10mr128937053pbd.105.1389052459035; Mon, 06 Jan 2014 15:54:19 -0800 (PST)
Received: from [192.168.1.100] (adsl-69-230-96-62.dsl.scrm01.pacbell.net. [69.230.96.62]) by mx.google.com with ESMTPSA id dq3sm131434822pbc.35.2014.01.06.15.54.17 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Jan 2014 15:54:18 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ted Krovetz <ted@krovetz.net>
In-Reply-To: <A6BDE08D-1F7D-4813-A9C4-61AF8C14412B@checkpoint.com>
Date: Mon, 6 Jan 2014 15:54:26 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <F2C64205-5DFA-4A8D-997F-F5AC7E6A4659@krovetz.net>
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>
To: Yoav Nir <ynir@checkpoint.com>
X-Mailer: Apple Mail (2.1827)
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: Mon, 06 Jan 2014 23:54:28 -0000

> An 8-byte nonce is part of ChaCha. 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?

Indeed it would. The Chacha core maps 48 bytes to 64 bytes and is called repeatedly on (32-byte key) || (8-byte IV) || (8-byte counter) to produce the output stream. Each distinct (8-byte IV) || (8-byte counter) will produce a pseudorandom 64-byte output. So, (n-byte IV) || (16-n-byte counter) should be just fine (so long as n is fixed for the life of the key).

-Ted