Re: [TLS] Salsa vs. ChaCha

Samuel Neves <sneves@dei.uc.pt> Thu, 28 November 2013 04:30 UTC

Return-Path: <sneves@dei.uc.pt>
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 23C7F1AE10A for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 20:30:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 kMpztMDdTPR2 for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 20:30:37 -0800 (PST)
Received: from smtp2.dei.uc.pt (smtp2.dei.uc.pt [193.137.203.234]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB9D1A1DFA for <tls@ietf.org>; Wed, 27 Nov 2013 20:30:37 -0800 (PST)
Received: from [192.168.1.71] (bl21-79-240.dsl.telepac.pt [2.82.79.240]) (authenticated bits=0) by smtp2.dei.uc.pt (8.14.4/8.14.4) with ESMTP id rAS4UEIT006546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <tls@ietf.org>; Thu, 28 Nov 2013 04:30:20 GMT
Message-ID: <5296C6D7.2040509@dei.uc.pt>
Date: Thu, 28 Nov 2013 04:30:15 +0000
From: Samuel Neves <sneves@dei.uc.pt>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: tls@ietf.org
References: <CAM_a8JzY8VGq+N-5YbDk_3EdXkKJzof1BtUTVY8pJev2HZ9U6g@mail.gmail.com> <1384850165.2542.13.camel@dhcp-2-127.brq.redhat.com>
In-Reply-To: <1384850165.2542.13.camel@dhcp-2-127.brq.redhat.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information
X-FCTUC-DEI-SIC-MailScanner-ID: rAS4UEIT006546
X-FCTUC-DEI-SIC-MailScanner: Found to be clean
X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-60.25, required 3.252, autolearn=not spam, ALL_TRUSTED -10.00, BAYES_00 -0.25, L_SMTP_AUTH -50.00)
X-FCTUC-DEI-SIC-MailScanner-From: sneves@dei.uc.pt
Subject: Re: [TLS] 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: Thu, 28 Nov 2013 04:30:40 -0000

On 19-11-2013 08:36, Nikos Mavrogiannopoulos wrote:
>
>  This was not our intention (and if there is some text that needs to be
> changed to prevent that, please let us know). Mainly what we want to say
> there, is that we do not want to evaluate any new cipher (we are not
> experts in cipher design). We select what is considered secure from the
> existing cryptographic competitions in order to replace RC4.

Section 7 does seem to focus a lot on the performance aspect of ChaCha.
In reality, ChaCha was designed to improve diffusion, which would
hopefully translate to more security per round. The speed advantages
were (mostly) incidental.

> If we follow the path to chacha, which is not the outcome of a cipher
> competition there can be arguments why not consider some other XXX
> stream cipher as well which could be better than ChaCha in some aspect.
> Such arguments would then be hard to confront.

I certainly understand the rationale of picking a co-winner (along with
Rabbit, HC-128, and SOSEMANUK) of a cryptographic competition. Nobody
ever got fired for that!

A few comments, though:

 - The most successful cryptanalysis performed on Salsa20 also analyzed
ChaCha [1, 2]. In each case, ChaCha withstood attacks with one fewer
round than its predecessor. ChaCha does seem to deliver on its goal of
more diffusion per round.

 - Zooko has mentioned BLAKE and its success against cryptanalysis, but
as noted this does not translate to a useful security reduction. It is
worth pointing out, however, that cryptographers chose to base the core
of their algorithm in the ChaCha quarter-round rather than the Salsa
quarter-round. This suggests equal or more confidence in ChaCha (see
also [4]).

 - There is a concurrent proposal to integrate Chacha20 + Poly1305 as a
TLS AEAD mode [3]. Implementors are unlikely to appreciate the
redundancy in having two separate, but very similar ciphers, in TLS (I
do realize that it makes just as much sense to ask Adam Langley to
change to Salsa20).

Ultimately, whatever variant ends up being chosen, I believe it's the
overwhelming consensus that it beats RC4.

[1] http://eprint.iacr.org/2007/472
[2] http://link.springer.com/chapter/10.1007%2F978-3-642-37682-5_24
[3] http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04#page-14
[4] http://www.ietf.org/mail-archive/web/cfrg/current/msg03491.html