Re: [TLS] Salsa20 and Poly1305 in TLS

Nikos Mavrogiannopoulos <> Tue, 30 July 2013 09:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1FB3A21E80C2 for <>; Tue, 30 Jul 2013 02:01:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Zu4dDIPbjRnn for <>; Tue, 30 Jul 2013 02:01:40 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c01::232]) by (Postfix) with ESMTP id 5B27521E80BC for <>; Tue, 30 Jul 2013 02:00:32 -0700 (PDT)
Received: by with SMTP id s1so1104765qcw.9 for <>; Tue, 30 Jul 2013 02:00:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=nEggyb6wLVZIAN5E7OkVb28H8d+HBdMIiABWAHuPI2g=; b=VZktEdRPNO75kIcAWXhs4FROF7kt4tYZnUx8aYmnrj8QrjOBKFZpO0qIxhAVDH3CHV RyD70Ue/ImkgGVh/WU+yNTpdugve8SRcpgzB8gguHrO1gxjAdixLmttn1gruJ/8Rkxzj mzSjZf+RvCzt5IaibwrJrZyJxUcoTATHx/i3n8GWi9grDRMG26Tzuu7ROIA/4vLm5Ujn c358yVbYcy+REPLfcfqaonxZhhO3mMSwQE11s+jylBqDy5r/nAzNdNDNe154DAOS0urZ ocC30ugd1/ZF7QZHqXeDTLxCr9qG+ZMD8Mv69gbz0P9laB7S41YbKn+pLKPWzxYQXES+ x0Lw==
MIME-Version: 1.0
X-Received: by with SMTP id jv8mr35687372qeb.34.1375174812663; Tue, 30 Jul 2013 02:00:12 -0700 (PDT)
Received: by with HTTP; Tue, 30 Jul 2013 02:00:12 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Tue, 30 Jul 2013 11:00:12 +0200
X-Google-Sender-Auth: KLeqVe22JgTEQXQm0XAzjAw9A9I
Message-ID: <>
From: Nikos Mavrogiannopoulos <>
To: Adam Langley <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>
Subject: Re: [TLS] Salsa20 and Poly1305 in TLS
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Jul 2013 09:02:00 -0000

On Mon, Jul 29, 2013 at 9:09 PM, Adam Langley <> wrote:
> I cannot make it to Berlin I'm afraid (or, indeed, any meetings until
> at least IETF 91) so I'm writing my thoughts on
> draft-josefsson-salsa20-tls-02, which is scheduled for discussion.
> Salsa20/12 is something that we are currently working on supporting.
> However, I believe that Poly1305 is superior to UMAC and we're looking
> at Salsa20/12+Poly1305, not UMAC. (Note: that's Poly1305 with the
> nonce generated directly by Salsa20/12, not via AES.)

Thanks. The choice between UMAC and Poly1305 is indeed an open issue right now.

> (For the following, I used UMAC in nettle 2.7 and Andrew M's
> implementation of Poly1305[1], both on a E5-2690@2.90GHz with
> Hyperthreading and Turboboost disabled.)
> UMAC96 (with AES for the nonce generation) takes 9146.1ns to
> authenticate 1K of data, HMAC-SHA1(1K) takes 3667ns and Poly1305 takes
> 561.4ns.
> However, that's not the whole story for UMAC because it can use 1.5KB
> of memory for precomputation, after which it can authenticate 1KB of
> memory in just 329ns with that in L1. That's typically the headline
> speed that's advertised.

That is, however, an important advantage in dedicated peer-to-peer
connections (e.g., VPN), which is how I test the current ciphersuites.

btw. was Poly1305 used with salsa20/12 in this comparison or AES? If
it is salsa20, I believe that the numbers would be quite different for
UMAC if used with salsa20 as well.

In any case, whether AES is used on the MAC (UMAC or Poly1305) or the
cipher of the ciphersuite is also an issue to be addressed. The only
issue for using the cipher instead of AES, is the fact that there are
no test vectors (in an RFC or any other document), and both of these
variants were defined using AES so by combining the MAC with another
cipher TLS will be quite unique. Nevertheless that idea of combining
them with the actual cipher in use is quite nice and has advantages in
a number of systems.

> Additionally, Poly1305 can be written in a tweet(*), while UMAC is
> dramatically more complex. Since they are both Wegman-Carter style
> hashes I believe that they both have, fundamentally, well understood
> security properties. (See [2] for a good overview.)

Complexity is indeed an issue, but tweetocity doesn't seem to be a
clear advantage :)

> Thus Poly1305 is looking much more attractive to us.

While I like UMAC, but I also see the advantages of Poly1305. In any
case, I think it would be a good idea to add them to the list (or even
replace umac if there are no clear advantages) if that draft proceeds.