Re: [TLS] Salsa vs. ChaCha

Nikos Mavrogiannopoulos <> Thu, 28 November 2013 16:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3698B1ACCE4 for <>; Thu, 28 Nov 2013 08:08:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k5ujIoCdo_7d for <>; Thu, 28 Nov 2013 08:08:34 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 602C21AC403 for <>; Thu, 28 Nov 2013 08:08:34 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id rASG8OcX030372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Nov 2013 11:08:25 -0500
Received: from [] ( []) by (8.14.4/8.14.4) with ESMTP id rASG8KOJ027194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Nov 2013 11:08:24 -0500
Message-ID: <>
From: Nikos Mavrogiannopoulos <>
To: Samuel Neves <>
Date: Thu, 28 Nov 2013 17:08:20 +0100
In-Reply-To: <>
References: <> <> <>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on
Subject: Re: [TLS] Salsa vs. ChaCha
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 28 Nov 2013 16:08:36 -0000

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