Re: [TLS] Salsa20 and Poly1305 in TLS

Adam Langley <> Tue, 06 August 2013 15:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF88821F9EB8 for <>; Tue, 6 Aug 2013 08:25:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.453
X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[AWL=-1.524, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, SARE_MLB_Stock6=1.56]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k9UBi42tESll for <>; Tue, 6 Aug 2013 08:25:43 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c02::231]) by (Postfix) with ESMTP id D123221F9C53 for <>; Tue, 6 Aug 2013 08:25:33 -0700 (PDT)
Received: by with SMTP id n10so983933oag.36 for <>; Tue, 06 Aug 2013 08:25:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nvn3xwThZWieF0TOJAq80oa+50onmZwlmwmHTiNhBRY=; b=KHrsL3j26TxsU/2838d7iHvTW5UiKM1gregkvyexwkOaOYyKJgiVjPTSNE2yte97aC rbv3ii0PNs+SXhm9OPihRRLj5orY7YBx+39KMgPT8/wol+kU61zCE2ZRJ275I/r7Cu92 k6sZq8vfso4A62sqh5U0PeAo/8UCPrSBtM5WdpNQHcvZFR11iKPsjlX6O0vvzecKK6W4 jKYfMnoMqcbdDH1bNX+V0lUu3EbQqRWvEKZiI0rKaC7x8xEP1G+SROeiMWk8x23ynyV6 rjZ8+CqcZC3QIwI2/CYNo2oUuPZL9ThhKQrDLXChzl2VwnwAG+t81E4zL6vZb3hfNiOm qgog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=nvn3xwThZWieF0TOJAq80oa+50onmZwlmwmHTiNhBRY=; b=pNqLjwY+/epkM4f3ErWQmvoLDCJDGZiXRuH0mmSE/I8qgo87tPSA3OdCmAjSkAh8Y3 sDwitMjXwosl7zbxOBhhS3tuCUMaAXICuIikflb0/tfBpj6M7hAfF8YeY3ADdJxlT5BO QrxS0RNVRTDMRQcAt7sE3+o71hfekhZKWYebacQzhyPyaMDO4aw/uNehf9BU7u7qiD3D sQQWhWgViJWOk8Up0OIM6RV9+ToOtVXzgI9uDfN35z/tbJDwk6p6aj3A+NFctHSb3Yc4 9RxMAvvP91fosid316KhspGI4W3DvbPNhxUzl+RQ9va6/jkD+ICEHhdVEeg0OY0voGAQ HXiQ==
X-Gm-Message-State: ALoCoQkTJrs7XCtdeOPZESh6ylZWX3HmoaBXV+6B6DxPqSXD2rc21Nijmq5USw1wfkVQclcZZ33LMteGxN5KVuL/+nF/8cF0IU+upA5uN4ZCODvH5/Bsamw1PsuoK5oP2UpclZ3n9aGziSUZ5A4X74rsS0F/IkNdQtd/CNjxAOzFiISn2HH+zSPX/rW/wEt4WE5a5+s91+ww
X-Received: by with SMTP id p8mr1411672oel.73.1375802733160; Tue, 06 Aug 2013 08:25:33 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 6 Aug 2013 08:25:12 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Adam Langley <>
Date: Tue, 6 Aug 2013 11:25:12 -0400
Message-ID: <>
To: Ted Krovetz <>
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, 06 Aug 2013 15:25:43 -0000

On Tue, Jul 30, 2013 at 10:45 AM, Adam Langley <> wrote:
> I will try to repeat the above benchmarks for VMAC this week. (And, hopefully, run some tests on ARM.)

Recap, to authenticate 1K of data:

UMAC96 (with AES for nonce generation, since Nikos suggested that was
the intended design previously): 9146ns
HMAC-SHA1: 3667ns
Poly1305: 561ns

On the same machine (E5-2690@2.90GHz with Hyperthreading and
Turboboost disabled), with VMAC code from

VMAC (128-bit, with AES calls removed in order to better compare to
Poly1305): 270ns with 248 bytes of memory

On a Cortex-A8 (specifically a Galaxy Nexus) using Linaro GCC 4.7:

VMAC (128-bit, with AES calls removed): 13203ns with 248 bytes of memory
Poly1305 (code from SUPERCOP):  3567ns

For VMAC I used ARM optimised code provided by Ted Krovetz.

Other, random measurements:

VMAC (128-bit, AES for nonces, Intel): 368ns with 424 bytes of memory
and 1308ns one-time key schedule.
VMAC (64-bit, no AES, Intel): 138ns, 360 bytes of memory.
VMAC (64-bit, AES, Intel): 229ns, 360 bytes of memory.
VMAC (128-bit, AES, ARM): 14322ns, 424 bytes of memory

For the ARM measurements I was careful to do them with the screen on
and unlocked. Android reduces the clock speed when the phone is

When measuring VMAC "with AES", I used "rijndael-alg-fst.c", not OpenSSL.

When removing AES from VMAC I just removed all AES calls and AES
related elements of the context structure. That's not intended to be a
real design, but a reasonable simulation for the purposes of timing.

Poly1305 is very fast on ARM, but VMAC is twice as fast on servers at
the cost of a bit of memory.

I think I'm still leaning towards Poly1305, but I could be persuaded
by VMAC, it's very impressive.