[Cfrg] Fwd: [TLS] Curve25519 in TLS and Additional Curves in TLS

Robert Ransom <rransom.8774@gmail.com> Thu, 23 January 2014 22:18 UTC

Return-Path: <rransom.8774@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A30511A02B8 for <cfrg@ietfa.amsl.com>; Thu, 23 Jan 2014 14:18:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 kkZN82VkiUzS for <cfrg@ietfa.amsl.com>; Thu, 23 Jan 2014 14:18:36 -0800 (PST)
Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDB11A0154 for <cfrg@irtf.org>; Thu, 23 Jan 2014 14:18:36 -0800 (PST)
Received: by mail-qa0-f43.google.com with SMTP id o15so2976103qap.2 for <cfrg@irtf.org>; Thu, 23 Jan 2014 14:18:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=DmAJZr29hiE122gECGqIEzMOzc+BBymyy76paN9Xjrk=; b=n7MMX49SdvOwHzxnA9oUNEtiCENmwEBWkwHkK9Go5vzkXtM7UmX48qjbbhON24hPN5 W/yJvMrROMAQsk57PnxI+1n84YnhEgXWF29QHDTUOIbYppp7rHAbN3LAbaEVOyJeGM92 5bEAG78tG+Tk8czqASAl0SgAXyIFeJ7BixkzrksdyXVhVWgWYOqHOV4r/9TBXmsXULUO INaZmozWdwMO9LDsCx0NV30ROMQnhxYo7GAQCdxjaWXA+OjU3UUlFh/Ia5DTQqmIpOF6 CuADiIaYuVamoBdUj6MdHUEYCnEYy2xGCp/hsee5868CSfSKZSvw3znMG31fzQHdw3ER E7Sg==
MIME-Version: 1.0
X-Received: by 10.140.32.228 with SMTP id h91mr14765661qgh.49.1390515515012; Thu, 23 Jan 2014 14:18:35 -0800 (PST)
Received: by 10.229.181.132 with HTTP; Thu, 23 Jan 2014 14:18:34 -0800 (PST)
In-Reply-To: <CABqy+sozYSOTh7pbUS2GXf=4kYV3zgztXZBa10Bx=s-N8zHHyA@mail.gmail.com>
References: <87ob3456s1.fsf@latte.josefsson.org> <CABqy+spt7BYqjsqLAkZssGp3aY9M+iLqV+pmyr7ZN-TXmJJpVg@mail.gmail.com> <52E060D0.9030801@polarssl.org> <CABqy+spJoswrPovxf18QS1SGdk6K=mfny6joJm3X24Vh65oagQ@mail.gmail.com> <52E0E241.40406@polarssl.org> <CABqy+sqs31ATDWJSum55m1o5pRvw8Wq5GtB-mF-hgP2emB5eFQ@mail.gmail.com> <CABqy+sozYSOTh7pbUS2GXf=4kYV3zgztXZBa10Bx=s-N8zHHyA@mail.gmail.com>
Date: Thu, 23 Jan 2014 14:18:34 -0800
Message-ID: <CABqy+soSojSMfx=yU9eFhmAeuJaJ_r=4h=RDR6JtOchYZ9zsQA@mail.gmail.com>
From: Robert Ransom <rransom.8774@gmail.com>
To: cfrg@irtf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: [Cfrg] Fwd: [TLS] Curve25519 in TLS and Additional Curves in TLS
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2014 22:18:37 -0000

This is relevant to CFRG discussions as well, and I don't know whether
everyone on the CFRG list is also subscribed to the TLS list.

---------- Forwarded message ----------
From: Robert Ransom <rransom.8774@gmail.com>
Date: Thu, 23 Jan 2014 13:37:18 -0800
Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in TLS
To: Manuel Pégourié-Gonnard <mpg@polarssl.org>
Cc: tls@ietf.org

On 1/23/14, Robert Ransom <rransom.8774@gmail.com> wrote:
> On 1/23/14, Manuel Pégourié-Gonnard <mpg@polarssl.org> wrote:
>> On 23/01/2014 02:17, Robert Ransom wrote:

>>> * If you do not add a leading point-format byte, there is no reason to
>>> specify the meaning of the high bit in this document.  If you do add a
>>> leading byte, you will have to choose in this document whether the
>>> sign bit is for the Edwards-form x coordinate or the Montgomery-form y
>>> coordinate.
>>>
>> Or we could add a leading byte now and say that the meaning of the msb is
>> not
>> defined yet an reserved for future use (which is what you suggest anyway,
>> IIUC).
>> Then a future document could update the meaning of this leading byte.
>
> I think that's easiest (provided that current implementations also
> accept 64-byte points and discard the second half; see below).

On further thought, there is a major technical benefit to sending
(either all of or a sign bit for) the Edwards-form x coordinate rather
than the Montgomery-form y coordinate.  Denoting the Montgomery-form
point as (u, v) and the Edwards-form point as (x, y), the isomorphism
from Montgomery form to Edwards form computes x = 2 u/v, which is
undefined for the point of order 2 (Montgomery (0, 0)).

I think that issue, combined with the fact that implementations which
use the sign bit will almost certainly use Edwards form internally,
should rule out any use of a Montgomery-form y coordinate in any
current or future protocol.

Since Curve25519's coordinate field order is congruent to 5 mod 8,
there is no notion of ‘principal square root’, and thus no plausible
alternative to using the least significant bit of a coordinate as its
sign bit.  So there is only one likely choice of sign bit for
Curve25519 group elements, and that is the LSB of the Edwards-form x
coordinate.

Now that I'm not worried about what will eventually be chosen as the
sign bit, the only reason I can see to use a leading magic byte in the
point format is to distinguish ‘the sender did not compute the sign
bit of this point’ from ‘the sender computed the sign bit of this
point, and it is 0’.  I have previously suggested that distinguishing
those cases could be useful, but now I think mitigation of
implementation fingerprinting is more important -- I see no reason to
advertise whether an implementation computes the sign bit of its group
elements or not, even if an attacker could infer that piece of
information after a series of connections.


Robert Ransom