Re: [TLS] Salsa vs. ChaCha

Nikos Mavrogiannopoulos <nmav@redhat.com> Thu, 28 November 2013 16:08 UTC

Message-ID: <1385654900.23418.33.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Samuel Neves <sneves@dei.uc.pt>
Date: Thu, 28 Nov 2013 17:08:20 +0100
In-Reply-To: <5296C6D7.2040509@dei.uc.pt>
References: <CAM_a8JzY8VGq+N-5YbDk_3EdXkKJzof1BtUTVY8pJev2HZ9U6g@mail.gmail.com> <1384850165.2542.13.camel@dhcp-2-127.brq.redhat.com> <5296C6D7.2040509@dei.uc.pt>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] Salsa vs. ChaCha
Precedence: list

On Thu, 2013-11-28 at 04:30 +0000, Samuel Neves wrote:
> 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).

I agree with your last point that the drafts should match to reduce the
number of algorithms needed in a TLS implementation. There is no point
to have both salsa20 and chacha.

To me it is pretty inexplicable why one would not want the winner of a
recent crypto competition in TLS but rather a modification of it (e.g.,
I haven't seen anyone arguing for another cipher in TLS when RIJNDAEL
was the winner of the NIST competition).

Nevertheless, if the TLS WG consensus is to use Chacha20/20 (or
Chacha20/12?) to replace RC4 instead of the estream's salsa20, it would
be very simple to draft a new text with it. What I didn't understand,
however, from the IETF88-TLS notes is whether it is planned to replace
RC4 at all (with a non-AEAD cipher that is).

regards,
Nikos

[TLS] Salsa vs. ChaCha Zooko Wilcox-OHearn
Re: [TLS] Salsa vs. ChaCha Nikos Mavrogiannopoulos
Re: [TLS] Salsa vs. ChaCha Samuel Neves
Re: [TLS] Salsa vs. ChaCha Nikos Mavrogiannopoulos
[TLS] chacha to replace RC4 (was: Salsa vs. ChaCh… Nikos Mavrogiannopoulos
Re: [TLS] chacha to replace RC4 (was: Salsa vs. C… Robert Ransom
Re: [TLS] chacha to replace RC4 (was: Salsa vs. C… Nikos Mavrogiannopoulos
Re: [TLS] chacha to replace RC4 (was: Salsa vs. C… Nikos Mavrogiannopoulos
Re: [TLS] chacha to replace RC4 (was: Salsa vs. C… Nick Mathewson
Re: [TLS] chacha to replace RC4 (was: Salsa vs. C… Nikos Mavrogiannopoulos
Re: [TLS] chacha to replace RC4 (was: Salsa vs. C… Robert Ransom
Re: [TLS] chacha to replace RC4 Manuel Pégourié-Gonnard
Re: [TLS] chacha to replace RC4 (was: Salsa vs. C… Samuel Neves
Re: [TLS] chacha to replace RC4 (was: Salsa vs. C… Brian Smith
Re: [TLS] chacha to replace RC4 (was: Salsa vs. C… Nikos Mavrogiannopoulos