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

Michael Hamburg <> Fri, 24 January 2014 02:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D3F121A0211 for <>; Thu, 23 Jan 2014 18:08:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.556
X-Spam-Level: *
X-Spam-Status: No, score=1.556 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IYObYjayjPom for <>; Thu, 23 Jan 2014 18:08:49 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2F3331A01BE for <>; Thu, 23 Jan 2014 18:08:48 -0800 (PST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 718063AA04; Thu, 23 Jan 2014 18:06:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=sldo; t=1390529190; bh=7rYF0+owFkR69MO+80UY+R/CvyvY8losCsHnhhodSIE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=d8m9fa0Ey/1i1VYjAw9+Y51s2RCThNBd1cmVqWKx4+Fx6rvLa0EdAtgam8z7z5dVz RP/ro4FdfXgdOQBROg5AcgcHbmVcK66caRtnt7ZEjHYbTOil4kpkUzjbvVISaCTg4b RYSjvXdyN+d7BwzC/mqU2d4BLp7/7tAi42JixLhE=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Michael Hamburg <>
In-Reply-To: <>
Date: Thu, 23 Jan 2014 18:08:45 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <>
To: Andrey Jivsov <>
X-Mailer: Apple Mail (2.1827)
Subject: Re: [Cfrg] [TLS] Curve25519 in TLS and Additional Curves in TLS
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Jan 2014 02:08:51 -0000

On Jan 23, 2014, at 4:59 PM, Andrey Jivsov <> wrote:
> Wouldn't be another method?
> Traditionally the problem was solved by carrying 1 bit and then finding a place to fit it in and defining what it means, etc. There is another way. One can adjust the private key to make the coordinate that we drop, x in this case, be the smallest of the two possibilities.
> The nice feature of my proposal is that you can still also encode the bit if you wish so, as you proposed.

This is interesting, but I think it works better with the Edwards x-coordinate instead of the Montgomery y-coordinate.  That is, it applies well to Watson’s (Montgomery x, Edwards x) representation.  This is because not every point you might want to transmit is a public key; it might be the product of something which does not support an easy negation, such as PAKE.  In this case, with your proposal, implementers have to send the sign bit, and we have two wire formats again.  But if the Edwards x-coordinate is used, you can also fast-adjust by adding the point of order 2, which maps EdX to -EdX.  (It maps EdY to -EdY and MontX to 1/MontX.)  If the protocol wipes out the cofactor (almost every protocol does for security reasons), then this is more likely to be acceptable than negating the point.

Then again, any discussion like this is fraught with issues about alternative encodings for non-wire formats, implementation compatibility, uniqueness, covert channels, etc.  Might take some hashing out.

— Mike