IETF Logo Mail Archive

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

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

Return-Path: <rransom.8774@gmail.com>
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 910A41A0140 for <tls@ietfa.amsl.com>; Thu, 23 Jan 2014 13:37:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.45
X-Spam-Level:
X-Spam-Status: No, score=-1.45 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, MIME_8BIT_HEADER=0.3, 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 NhArbNXxVrQ6 for <tls@ietfa.amsl.com>; Thu, 23 Jan 2014 13:37:19 -0800 (PST)
Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8C01A00C9 for <tls@ietf.org>; Thu, 23 Jan 2014 13:37:19 -0800 (PST)
Received: by mail-qa0-f54.google.com with SMTP id i13so2957038qae.27 for <tls@ietf.org>; Thu, 23 Jan 2014 13:37:18 -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 :cc:content-type:content-transfer-encoding; bh=rPuZ9wnckyRwANwEOatw4K67GZpSq6ydtctbcqBaqhE=; b=06a9worltmaHzLbxpa39MNhUejuo3RDkmTmY3yU1KmWNSbnkncxa5iTURiqP5AY9k0 uiuOUQf4zkI6KK6ly7mFWpkFF8jbG3X8mCj946ggA00q+C8D8PH/U5+63AO5cmAGHlDd pyqurMlJKJK2nKiuyCQOOU/MqJ8/MIwSdq5zlvuDcvt19OdZillx/gBsmN8N/yzuFVJm RUYN2i0M/7wrGECG1cEm/tKjoqW+G1kvF/a4z/5EWSL3i4GwltZwovdIeobhkQXrAfIY d640AZoEZF3CvBQhNeHNmW7NMq29bTNA9qfgK0A1zDow7lKHn7sFvg8zMXN3c1zRIvXV vKlg==
MIME-Version: 1.0
X-Received: by 10.224.46.8 with SMTP id h8mr15397796qaf.49.1390513038172; Thu, 23 Jan 2014 13:37:18 -0800 (PST)
Received: by 10.229.181.132 with HTTP; Thu, 23 Jan 2014 13:37:18 -0800 (PST)
In-Reply-To: <CABqy+sqs31ATDWJSum55m1o5pRvw8Wq5GtB-mF-hgP2emB5eFQ@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>
Date: Thu, 23 Jan 2014 13:37:18 -0800
Message-ID: <CABqy+sozYSOTh7pbUS2GXf=4kYV3zgztXZBa10Bx=s-N8zHHyA@mail.gmail.com>
From: Robert Ransom <rransom.8774@gmail.com>
To: Manuel Pégourié-Gonnard <mpg@polarssl.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Thu, 23 Jan 2014 21:37:20 -0000

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

v2.23.0 | Report a Bug | By Email