Re: [TLS] Salsa20 and Poly1305 in TLS

[Adam Langley <[e-mail]>]

On Tue, Jul 30, 2013 at 10:45 AM, Adam Langley <[e-mail]> 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 fastcrypto.org:

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
`asleep'.

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.


Cheers

AGL