Re: [Cfrg] Safecurves draft

Mike Hamburg <> Thu, 09 January 2014 18:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9C08E1AE26E for <>; Thu, 9 Jan 2014 10:07:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.557
X-Spam-Level: *
X-Spam-Status: No, score=1.557 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, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KaL9INq5CJgL for <>; Thu, 9 Jan 2014 10:07:36 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 30E201AE04C for <>; Thu, 9 Jan 2014 10:07:36 -0800 (PST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id B82F43AA04; Thu, 9 Jan 2014 10:06:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=sldo; t=1389290765; bh=SdpHQwKGMwdUJlPJp4qVkbO8hTLJUtBxMFwWol4S2X0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=HPp8mTV+4pLznOj+lKilh9StQd3T2toXB+xqwlODyosk1qDBxPfwFOt1ai8JJ8Se5 HXnT+3kluR4a+BGfHf3uuZJQirPUfj93FzN/uPUk11SrG9aoMA9KJdc8m/8O0zd0Rr dWgU9fcc0rIziCgS1qL74tyZjbO/EFkVPy2gMUUA=
Content-Type: multipart/alternative; boundary="Apple-Mail=_71CF6819-6A8C-44BE-88D1-4DD86AFCA136"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Mike Hamburg <>
In-Reply-To: <>
Date: Thu, 09 Jan 2014 10:07:24 -0800
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Bodo Moeller <>
X-Mailer: Apple Mail (2.1827)
Cc: "" <>
Subject: Re: [Cfrg] Safecurves draft
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: Thu, 09 Jan 2014 18:07:37 -0000

On Jan 9, 2014, at 7:26 AM, Bodo Moeller <> wrote:

> Robert Ransom <>:
> > So while the Montgomery-form Curve25519 certainly has its use, allowing
> > applications to negotiate a different form for ECDH would be beneficial.
> Even if the party which generates a public key uses Edwards-form
> points internally for that operation, whoever generates the key can
> put it into Montgomery form for free before scaling, whereas whoever
> receives it would need to perform an extra coordinate inversion in
> order to convert from Edwards form to affine Montgomery form.
> That's a good point.  As I've pointed out (or tried to point out, anyway), the receiver might want to do the computations in Edwards form too, but there's not that much to be gained from that, so it may not be worth the extra complexity.
> Bodo

I agree.  The sender might well use Edwards internally -- it's about 3x faster -- but the point should be sent in Montgomery form.

I wonder, though, if the standard encoding of the spec should have the sign of the y-coordinate.  That way if we want to use the format for something other than ECDH -- signatures or PAKE or whatever -- we won't have to specify a new encoding.

An overly-complicated but cute solution is 1/sqrt(x) chosen with the same sign as y.  (x is always square if you're in the q-torsion; 1/x works just as well as x in the ladder; 1/x lets you encode the identity.)  But we probably don't actually want to spec that.  Maybe just a bit for sign(y)?

-- Mike