Re: [TLS] Curve25519 in TLS and Additional Curves in TLS

Manuel Pégourié-Gonnard <mpg@polarssl.org> Fri, 11 April 2014 08:05 UTC

Return-Path: <mpg@polarssl.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FED81A044A for <tls@ietfa.amsl.com>; Fri, 11 Apr 2014 01:05:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.471
X-Spam-Level:
X-Spam-Status: No, score=-0.471 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-POKSWWjxlM for <tls@ietfa.amsl.com>; Fri, 11 Apr 2014 01:05:11 -0700 (PDT)
Received: from mordell.elzevir.fr (mordell.elzevir.fr [92.243.3.74]) by ietfa.amsl.com (Postfix) with ESMTP id 040241A0445 for <tls@ietf.org>; Fri, 11 Apr 2014 01:05:11 -0700 (PDT)
Received: from thue.elzevir.fr (thue.elzevir.fr [88.165.216.11]) by mordell.elzevir.fr (Postfix) with ESMTPS id 35F93161AF; Fri, 11 Apr 2014 10:05:06 +0200 (CEST)
Received: from [192.168.0.124] (unknown [192.168.0.254]) by thue.elzevir.fr (Postfix) with ESMTPSA id 3A80A29043; Fri, 11 Apr 2014 10:05:05 +0200 (CEST)
Message-ID: <5347A22B.9000903@polarssl.org>
Date: Fri, 11 Apr 2014 10:04:59 +0200
From: Manuel Pégourié-Gonnard <mpg@polarssl.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos <nmav@redhat.com>, Alyssa Rowan <akr@akr.io>
References: <87ob3456s1.fsf@latte.josefsson.org> <20140402164340.GA14790@roeckx.be> <20140407115102.3011d2e5@latte.josefsson.org> <CACsn0cmFLO2n8d-FVVb4wu=G5T88E7rRd8b=eYo-1uMZnMxkOQ@mail.gmail.com> <5344BD77.2020106@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18CAE@USMBX1.msg.corp.akamai.com> <1397044231.4019.4.camel@dhcp-2-127.brq.redhat.com> <4abda243-3fc2-4087-92f8-3db02769384f@email.android.com> <1397048457.4019.22.camel@dhcp-2-127.brq.redhat.com> <CACsn0ckyaGO9hqn7pDVE2VR-TWs5v+Y6NsnCqCvrwFGyUGfZ3A@mail.gmail.com> <1397118165.2419.23.camel@dhcp-2-127.brq.redhat.com> <5346FEDE.9000909@akr.io> <1397201622.2324.13.camel@dhcp-2-127.brq.redhat.com>
In-Reply-To: <1397201622.2324.13.camel@dhcp-2-127.brq.redhat.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EQucI8BjmVo1_RkSeilZXVDhg4A
Cc: tls@ietf.org
Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 11 Apr 2014 08:05:13 -0000

On 11/04/2014 09:33, Nikos Mavrogiannopoulos wrote:
> On Thu, 2014-04-10 at 21:28 +0100, Alyssa Rowan wrote:
> 
>>> And how does this affect an ephemeral key exchange?
>> Assuming all side-channel attacks require repetition seems like the
>> kind of rather dangerous thinking that has bought TLS very unpleasant
>> surprises in the past. We've had quite enough of those already, I think.
> 
> Could you elaborate on how to achieve repetition on a protocol that runs
> only once with the same key? I find your argumentation hard to follow.
> 
I think Alyssa's point was not that you can achieve repetetion, but that
progress in the attacks may some day lead to powerful attacks that don't need
repetition at all.

How much information the attacker can get in one pass depends on many factors,
such as the attacker's abilities (noised timing only and real-time power trace
are very different settings) and the implementation techniques. With a naive
double-and-add algorithm (on a short Weierstrass curve, no using unified
formulas) and an attacker able to get a precise enough power trace, I don't
believe the attacker needs repetition to get the full ephemeral key.

Of course this is a fairly extreme example, but I think it shows side-channels
are not entirely irrelevant for ephemeral keys, at least in some contexts.

That said, I agree that side-channels are probably much less of a threat for
ephemeral keys than for long-term keys in most settings.

Manuel.