Re: [TLS] Salsa20 and Poly1305 in TLS

Ben Laurie <benl@google.com> Tue, 30 July 2013 09:40 UTC

Return-Path: <benl@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B6721E80C8 for <tls@ietfa.amsl.com>; Tue, 30 Jul 2013 02:40:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXjh1dijvZrr for <tls@ietfa.amsl.com>; Tue, 30 Jul 2013 02:40:52 -0700 (PDT)
Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A13FE11E81C8 for <tls@ietf.org>; Tue, 30 Jul 2013 02:40:47 -0700 (PDT)
Received: by mail-oa0-f46.google.com with SMTP id l10so1291282oag.33 for <tls@ietf.org>; Tue, 30 Jul 2013 02:40:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VzMQ+dUmZ2PIMwpDIfDEM2dCDJITBwHa3cOfRjR7Ysg=; b=g1xnkn2LbsPRiNsHV6vE7bPZOsL5i9fdcJKOsyw8ddJEwzjN38eLLCP95lVhIUpv3V jjqMGRHJd6PxwdW/7f+g/pOjs/NJs4i+Ex4mfu4RiaNOAG6Vycjbgw9h5IoiODpoWRCC z3Io7npO/2If/Nc8edM5dYNyfbAS2rFsPUbNTxpE2hVQ75lB5hf2eh+8ArPVB6NLAt00 sc0/R2ROIbuGBVxu2G9yt8RPDjmwVKm9U8nsnqKrMc88losUWqNOlUDR7InsgKLQi884 1+qY0AteehDxrYIpcjDJgfVUVMOgN0RXnk0lcmB7/f6ZyqBRU9oEMi/od9g97XdB/aiL hhhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=VzMQ+dUmZ2PIMwpDIfDEM2dCDJITBwHa3cOfRjR7Ysg=; b=AMraTTaKgGFls+SDG4vUOITjw/ufUhl1ODP6U9VFnhht0caX3yQ2qA5UEq8s9A2Aqu r3+IutHAi19w40pH14nbo8BOpjaS+gknxm/Q3lHb8RbxSmigmW08D4cC2JxzVk1auEQK 5RV7ERHfVTe4oDTQMXrbNqXsgaheZ/5LAjAygvRq9FaREgbIhrZJX47MwOXIMbgBhGFh 2t5soip5Nlw35bKPVVrrSzJK3r78MutyBennUoxyCXu5I5yrenBGS16JNMLdI97Diw3L EXfPupKxEzseXqiGXmrD6vdgjulRcZNmh+b912A5pAaGJG5J1ZBuNykV/0qvB0ONL52h KJmg==
MIME-Version: 1.0
X-Received: by 10.43.57.9 with SMTP id we9mr22159375icb.90.1375177227206; Tue, 30 Jul 2013 02:40:27 -0700 (PDT)
Received: by 10.64.230.239 with HTTP; Tue, 30 Jul 2013 02:40:27 -0700 (PDT)
In-Reply-To: <CAL9PXLySuS1gn8YisobYrbEnNpxJuYPbKB0qtkCOMnb+m90Jjg@mail.gmail.com>
References: <CAL9PXLySuS1gn8YisobYrbEnNpxJuYPbKB0qtkCOMnb+m90Jjg@mail.gmail.com>
Date: Tue, 30 Jul 2013 10:40:27 +0100
Message-ID: <CABrd9SRUNaWS-DDPy4+dVJUuaTfAnCo2SKhrMc8PPOKqiqf9tQ@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Adam Langley <agl@google.com>
Content-Type: multipart/alternative; boundary=bcaec51b1b9f21a44604e2b76651
X-Gm-Message-State: ALoCoQk2NKJ6H6BSCyLaQTscQlC/HD6NRNP9PXPZaY3sD69wECeCz0MhPQPxbITAqL90m3wKbvK7pwClQdesdewx2PweJKquB7rg8BqcCjIb2Q7kFNJ2174zklQbTzBD2KA7BCot8bEegnrcn7pt5NvmW9HND+zPD3La63Sd9fxzoBhcROV0I/CDzM+j6MmVpZoSRqkVhihT
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Salsa20 and Poly1305 in TLS
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: Tue, 30 Jul 2013 09:40:59 -0000

Also, defining ciphersuites for SSL 3, TLS 1.0/1.1 would be good, so we can
use them despite downgrade attacks.


On 29 July 2013 20:09, Adam Langley <agl@google.com> 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.
>
> We (Google) support the addition of Salsa20 as a cipher in TLS. Having
> a secure cipher which is fast and constant time on all platforms is
> important. It's also good to have an alternative to AES in the wings
> should that be needed in the future. At the moment I consider RC4 and
> AES-CBC to be mortally wounded, even if we have to continue supporting
> them for many years yet.
>
> 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.)
>
> (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.
>
> However, I consider cache pressure to be a way of cheating on
> benchmarks :) Benchmarks don't show cache pressure until the algorithm
> itself spills the L1 cache but, in a real system, cache costs.
>
> With the precomputed data only in L3 cache (tested by cycling through
> 10,000 contexts), UMAC takes 922.16ns to authenticate 1KB.
>
> So UMAC may give a small benefit to cases with few, busy connections,
> but it's a loss in the case where there are many connections (a
> server), or a few connections, intermittently used (i.e. a web
> browser).
>
> 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.)
>
> Thus Poly1305 is looking much more attractive to us.
>
>
> (* Here's an attempt in 159 chars: "Take msg in 16 byte chunks. Append
> 1 to each msg chunk&0-pad to 17 bytes. Interpt little-endian. Calc
> polynom in key[:16] mod 2^130-5. Add key[:16]. Mod 2^128.")
>
> [1] https://github.com/floodyberry/poly1305-donna
> [2] http://eprint.iacr.org/2013/144.pdf
>
>
> Cheers
>
> AGL
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>