[TLS] comparison of draft-josefsson-salsa20-tls-02 and draft-agl-tls-chacha20poly1305-02

Nikos Mavrogiannopoulos <nmav@gnutls.org> Wed, 23 October 2013 09:33 UTC

Return-Path: <n.mavrogiannopoulos@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 47C7B11E82B8 for <tls@ietfa.amsl.com>; Wed, 23 Oct 2013 02:33:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id rysSENHDAPkR for <tls@ietfa.amsl.com>; Wed, 23 Oct 2013 02:33:46 -0700 (PDT)
Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5345011E80F8 for <tls@ietf.org>; Wed, 23 Oct 2013 02:33:43 -0700 (PDT)
Received: by mail-ee0-f44.google.com with SMTP id b47so311214eek.31 for <tls@ietf.org>; Wed, 23 Oct 2013 02:33:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :openpgp:content-type:content-transfer-encoding; bh=CkO4H9+at2Vbo9bQMIps+IGYd2btS3trUfm02HUUrpw=; b=G9eoO62wM2f1pIUkXOYT0mSPhaCTtQ6XZH5pNcljm1kk9ZBELkd4GBlNRZ6Fc5j1me WZHuMIndfcV62px99GcWOS0WVTLLcoR4j8ZorQNZ4Hns4vlBSlpDpYwTHG8KQ2K19qfF m0ulCSl25oZbWbwaKfgWfaTDNycG4SezImIfp02hPeutTpvQ0pe/wMTdWO6oA/nWa1K0 ouWfwaAK146LDlyJxWXpebahO0CL/AUCd1Zh764shb+g/glyxgg9ctdNnCRCtJAEmiVm LlMmwiJh0kMiP2qVDqlo0awcHdmGSAvnaz8OvpBtJIUupiTU78uCmKUxyMiDrTRmW5xh 3UVQ==
X-Received: by with SMTP id v45mr814846een.52.1382520821194; Wed, 23 Oct 2013 02:33:41 -0700 (PDT)
Received: from [] (ip-62-245-100-42.net.upcbroadband.cz. []) by mx.google.com with ESMTPSA id w6sm57250892eeo.12.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 02:33:40 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <526797EE.2000206@gnutls.org>
Date: Wed, 23 Oct 2013 11:33:34 +0200
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7
MIME-Version: 1.0
To: "tls@ietf.org" <tls@ietf.org>
X-Enigmail-Version: 1.5.1
OpenPGP: id=96865171
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Cc: =?windows-1252?Q?Joachim_Str=F6mbergson?= <joachim@secworks.se>
Subject: [TLS] comparison of draft-josefsson-salsa20-tls-02 and draft-agl-tls-chacha20poly1305-02
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 23 Oct 2013 09:33:47 -0000

 We are about to update draft-josefsson-salsa20-tls-02 by replacing
UMAC-AES with POLY1305-AES, and given the opportunity we made a
comparison of the two drafts that add a new stream cipher to TLS. That
is draft-josefsson-salsa20-tls-02 and draft-agl-tls-chacha20poly1305-02.

* Salsa20 vs Chacha

draft-josefsson-salsa20-tls-02 uses Salsa20, a winner of an
international competion of stream ciphers (eStream), which is easily
implementable without leaking information through side-channels (i.e.
timing attacks).

draft-agl-tls-chacha20poly1305-02 selects Chacha instead, a derivative
of Salsa20 that has been shown to be 7% faster in hardware and occupy
10% less space [0]. However, it only combines that cipher with a MAC
that is of questionable efficiency in hardware (according to CFRG
synopsis). This results overall, in a combination that isn't really well
suited for hardware.

Nevertheless, even if draft-agl-tls-chacha20poly1305-02 could be made
efficient in hardware, in our opinion the performance benefits don't
justify switching from a winner of an international competition to
another algorithm (even if it is a derivative of it).

* Applicability to Datagram TLS

The draft-agl-tls-chacha20poly1305-02 is only applicable to TLS and not
DTLS. That is because its combination with poly1305-chacha results to an
RC4-like effect where rearranged or lost packets result in a
desynchronization of the peers. draft-josefsson-salsa20-tls-02 applies
to both TLS and DTLS (this results from the choice of having the block
cipher AES in UMAC-AES). Having a stream cipher in DTLS was a main
reason (for me at least) for draft-josefsson-salsa20-tls-02.

* Adding a new cipher in stream or AEAD mode?

The draft-josefsson-salsa20-tls-02 draft adds a new cipher to existing
implementations and can be combined with the existing MAC algorithms in
TLS (i.e., HMAC-SHA1). That is not the case in the
draft-agl-tls-chacha20poly1305-02 draft, where a single combination is
registered (of chacha with poly1305). Adding additional combinations in
the latter draft would require defining more AEAD modes, something that
could be a significant barrier that prevents its implementation (in
contrast with just replacing a cipher in the stream setting of TLS).

While I understand that there is quite some argumentation for using the
AEAD mode in TLS for every cipher/mac combination I don't find it
particularly convincing. In this specific case the AEAD mode adds 8
bytes of explicit nonce to the TLS record packet without providing any
clear advantages compared to the original stream cipher interface.

* An interesting observation on the usage of EtA in
draft-agl-tls-chacha20poly1305-02 vs AtE.

Both drafts introduce a universal hash based MAC. However, the
chacha-poly1305 draft uses the encrypt-then-authenticate (EtA)
construction while the salsa20 draft uses TLS' authenticate-then-encrypt
(AtE) construction. When combined with ideal ciphers and MAC algorithms
both modes can be equivalent. However, the AtE construction has the
advantage of not revealing the MAC nor the authenticated data to an
adversary. Interestingly enough the only known attacks on universal hash
based MACs require access to MAC and data [1]. That is, these attacks
(the key guessing and the divide and conquer) do not directly apply to

Of course these attacks are of high complexity and impractical (unless
some other weakness in the TLS protocol, or the MAC algorithm is found),
but they nevertheless reinforce the view that the AtE construction has
advantages on non-ideal MAC algorithms.

best regards,

[0]. Henzen, Luca, et al. "VLSI hardware evaluation of the stream
ciphers Salsa20 and ChaCha, and the compression function Rumba."
Signals, Circuits and Systems, 2008. SCS 2008. 2nd International
Conference on. IEEE, 2008.

[1]. Handschuh, Helena, and Bart Preneel. "Key-recovery attacks on
universal hash function based MAC algorithms." Advances in
Cryptology–CRYPTO 2008. Springer Berlin Heidelberg, 2008. 144-161.