Re: [TLS] chacha to replace RC4 (was: Salsa vs. ChaCha)

Robert Ransom <rransom.8774@gmail.com> Fri, 06 December 2013 16:42 UTC

Return-Path: <rransom.8774@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47651AE342 for <tls@ietfa.amsl.com>; Fri, 6 Dec 2013 08:42:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 WuYDwuHYmzua for <tls@ietfa.amsl.com>; Fri, 6 Dec 2013 08:42:27 -0800 (PST)
Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 91E4E1AE348 for <tls@ietf.org>; Fri, 6 Dec 2013 08:42:27 -0800 (PST)
Received: by mail-qc0-f173.google.com with SMTP id m20so634875qcx.4 for <tls@ietf.org>; Fri, 06 Dec 2013 08:42:23 -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=9xyLqhWdDpPZpyhGAXurU4DpGtGmgmAzNfvcYj8QYww=; b=xF6iavRDtkj95TDQIehLFxdmS/jj8s4KVvkdxIfPnvsK9FQ86wdY1py6Ffidw5Q6Gp woJ7RhcIMECcBIH8KZmfMIJPBUYkyoPWMmuARrtUv/6OIME5bgMC42MTLTXm3YLfBuDP mWMuwguomyhaNfMtfsfhTFeRAmOjfnxfzxg0TFzt2HtNMUyfJcPC4Sh0Y5PZaV/k2hsh i+VEhleKr928V01SCdPsemg9beWWxUZkUBFl783a+y8S05t8IBZ3x+QrNhV24i20RLRd LL/RYO61ChM7LOB9W/jvQpH/XX3p/Kel5GBgn1q7M+KkczTn+9qOLjkaSyFG+7JhUQyK cEsg==
MIME-Version: 1.0
X-Received: by 10.224.73.200 with SMTP id r8mr8167305qaj.72.1386348143728; Fri, 06 Dec 2013 08:42:23 -0800 (PST)
Received: by 10.229.8.3 with HTTP; Fri, 6 Dec 2013 08:42:23 -0800 (PST)
In-Reply-To: <CAKDKvuw0EKJpbGxOmGGUHK3m0fOy43wwCLh3ZO-a06xrK2Mebg@mail.gmail.com>
References: <CAM_a8JzY8VGq+N-5YbDk_3EdXkKJzof1BtUTVY8pJev2HZ9U6g@mail.gmail.com> <1384850165.2542.13.camel@dhcp-2-127.brq.redhat.com> <5296C6D7.2040509@dei.uc.pt> <1386332388.3430.22.camel@dhcp-2-127.brq.redhat.com> <CABqy+spiBPaGrk7ipeWvC2Z_B=MeDVZAmmEbXL-Pa2Lf-6UA2Q@mail.gmail.com> <1386336151.3430.34.camel@dhcp-2-127.brq.redhat.com> <CAKDKvuw0EKJpbGxOmGGUHK3m0fOy43wwCLh3ZO-a06xrK2Mebg@mail.gmail.com>
Date: Fri, 6 Dec 2013 08:42:23 -0800
Message-ID: <CABqy+sr2-7E1+r7d4W0H2aLT+pSBjeC7yLd9Uj0tovG=Owjogw@mail.gmail.com>
From: Robert Ransom <rransom.8774@gmail.com>
To: Nick Mathewson <nickm@torproject.org>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] chacha to replace RC4 (was: Salsa vs. ChaCha)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Dec 2013 16:42:29 -0000

On 12/6/13, Nick Mathewson <nickm@torproject.org> wrote:

> The issue is that most implementations (all the ones I've seen,
> actually, and Robert has probably looked at more than I have) have an
> interface where you specify the number of bytes of output up front,
> and generate.  They do not have an incremental "generate the next N
> bytes of the stream" function.

Some of Dr. Bernstein's implementations in SUPERCOP do have an
incremental interface (specified by eSTREAM).  The main difficulty
with those implementations is that the interface requires callers to
encrypt an integral number of blocks with each call except the last.

Since Salsa20 and ChaCha are well known to encrypt merely by XORing
keystream into data, this could be worked around using an external
buffer, but that's an ugly piece of extra work.

> That said, it's pretty trivial to adopt _any_ of the implementations
> I've seen so that they would run incrementally; it's not a difficult
> programming problem.  You'd need to add 512 bits of memory overhead
> for each chacha instance, and you'd take a little performance overhead
> from the bookkeeping, but that's not a huge deal.

To get the performance that people expect from these stream ciphers,
one would need to buffer (at least) three or four blocks, since the
fastest implementations (Ted Krovetz's) generate three or more blocks
in parallel.


Robert Ransom