[Cfrg] Fwd: Complexity of the Microsoft curve proposal

Watson Ladd <watsonbladd@gmail.com> Thu, 16 October 2014 00:25 UTC

Return-Path: <watsonbladd@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 2DE141ACEAD for <cfrg@ietfa.amsl.com>; Wed, 15 Oct 2014 17:25:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.3
X-Spam-Level: *
X-Spam-Status: No, score=1.3 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_92=0.6, 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 PNdC5gwKtHUC for <cfrg@ietfa.amsl.com>; Wed, 15 Oct 2014 17:25:26 -0700 (PDT)
Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A49E1ACEAC for <cfrg@irtf.org>; Wed, 15 Oct 2014 17:25:26 -0700 (PDT)
Received: by mail-yh0-f51.google.com with SMTP id t59so1129370yho.10 for <cfrg@irtf.org>; Wed, 15 Oct 2014 17:25:25 -0700 (PDT)
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=xLVcrlcKr7Y1mClCvrmkCHRWFpPkNl9hXIYEIyF2luo=; b=DQad9fFdNoe2OltR12An/GzRMESUMrAIdrDDVd/ydpHjEswuSQSQr8ozMoKRsxgz1E KJVFHLmONMNQRVaq5F9zbF18hCOIJ6mWxTABbKO5JhIi8lJMthPezhSoh6gscBkiIpqp xpIDRyjiASsm3xSEm8x8u0U6L1AOXXqWMqCigfV3UQbw2aAKJOySmrzhQXAnwrkv34w6 6O3lI4S5tcu1gs245kxJizLl5ugYhOS+RudzBsGy+yVw0Q+l1pBdptL9C/eTuantnQ0V YX5I/snCNkdmdjqsQ8aisSCnKOxlrvjBCnLvJZqNIkf6XR5J9Upv9+MuVfDp84Gt6gsW +eKA==
MIME-Version: 1.0
X-Received: by 10.236.115.132 with SMTP id e4mr15502748yhh.10.1413419125492; Wed, 15 Oct 2014 17:25:25 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Wed, 15 Oct 2014 17:25:25 -0700 (PDT)
In-Reply-To: <CACsn0ckAVEh0gUXZHq1oC=o5wM-EYyNN3kf=3afeNCmJN0gJog@mail.gmail.com>
References: <075fdb98d04b42d08e39dbc706cc21fa@DM2PR03MB495.namprd03.prod.outlook.com> <253D0648-0DDE-497E-8BC1-4DD2805640E4@shiftleft.org> <CACsn0ckAVEh0gUXZHq1oC=o5wM-EYyNN3kf=3afeNCmJN0gJog@mail.gmail.com>
Date: Wed, 15 Oct 2014 17:25:25 -0700
Message-ID: <CACsn0cmx=Wrxzx0asnVuE7OskL_-R=KOGB2WBK2rX=h4jKO0zQ@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/r-LIFOnU35egqyDERhta6lt3lh8
Subject: [Cfrg] Fwd: Complexity of the Microsoft curve proposal
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, 16 Oct 2014 00:25:28 -0000

On Tue, Oct 14, 2014 at 6:03 PM, Michael Hamburg <mike@shiftleft.org> wrote:
>
> On Oct 14, 2014, at 4:54 PM, Craig Costello <craigco@microsoft.com> wrote:
>
> Hi Watson,
>
> To elaborate a little on what Mike said, when p == 3 mod 4, defining
> searches for twist-secure curves that minimize the absolute value of the
> Montgomery constant automatically minimize the absolute value of the
> constant on the isogenous (complete) Edwards curve and the absolute value of
> the constant on the isogenous twisted Edwards curve. So regardless of
> whether our curves are implemented using Edwards coordinates, twisted
> Edwards coordinates, or Montgomery coordinates, the corresponding curve
> constant will be small (see Section 2 of http://eprint.iacr.org/2014/027.pdf
> or Section 3.3 of http://eprint.iacr.org/2014/130.pdf to see that there is
> no problem here).
>
> On the other hand, I’m not sure if this happens when p == 1 mod 4: for
> example, the Edwards version of Curve25519 has a curve constant that’s a
> fraction of small numbers, which the implementation documented in
> http://eprint.iacr.org/2011/368.pdf ends up treating as a generic (large)
> field element.
>
>
> This is because Bernstein et al specified an isomorphic curve and not an
> isogenous one.  They could have specified the 4-isogenous curve
>
> x^2 + y^2 = 1 + d x^2 y ^2 where d = (2-A)/4 = -121665.
>
> [
> At least if I haven’t made a mistake:
>   x = 4v(u^2-1) / ((u^2-1)^2+4v^2)
>   y = u (4v^2 - (u^2-1)^2) / (2v^2(u^2+1) - u(u^2-1)^2)
>
> dual:
>   u = y^2/x^2
>   v = y(x^2+y^2-2)/x^3
> ]
>
> or the curve
>
> -x^2 + y^2 = 1 - d x^2 y^2
>
> which is isomorphic to that one under the map x -> ix.  Both of these curves
> are complete, because GF(2^255-16)(+-121665) is nonsquare.
>
> All other things being equal, I therefore think that switching between
> coordinates (if desired) slightly favors p == 3 mod 4.
>
>
> There are advantages to p == 3 mod 4, but I don’t think this is one of them.
> Note that p == 1 mod 4 supports curves which are both twisted [a=-1] and
> complete, but 3 mod 4 does not.  So in terms of coordinate systems, that’s
> the simplest, fastest option.  You can recover most of that with the isogeny
> trick, but not all of it.
>
> Furthermore, in this case, if the curve is defined as an a=1 (complete)
> Edwards curve, implementers then have the option of staying in Edwards form
> at the expense of 1 field multiplication per addition operation (like the
> implementation of Curve41417 inhttp://eprint.iacr.org/2014/526.pdf does) or
> of using Mike’s isogeny trick for enhanced
> performance:http://eprint.iacr.org/2014/027.pdf).
>
>
> I think Watson’s points were:
> 1) If the NUMS curves are chosen, they should be changed to the isogenous
> untwisted ones.
> 2) Whatever curves are chosen, they should compress points.

That's exactly right. I want the simplest, fastest, possible solution.
Simplicity matters more because most implementations need to favor
correctness over speed. But speed also matters, to avoid temptation.
So if twisted coordinates are complete, that works great. If not, we
should use untwisted coordinates, so that simple implementations are
secure implementations.

Sadly 2^521-1 is likely to be the prime we need to use for the big
workfactor because of performance/lack of nice primes in that range,
and is 3 (mod 4), so likely untwisted Edwards coordinates will have to
be used for signatures if we want to minimize the number of coordinate
systems used. (The penalty for a performant multiplication with
Edwards coordinates of either twistedness in code size is fairly
large, and the isogeny trick requires implementing arithmetic in the
group order. On the other hand, for signatures this is likely already
needed. In comparison, Montgomery form is very compact in code, even
when performant)

Point compression incurs a slight penalty. However, it entirely
eliminates a class of attacks caused by not checking the order,
provided the square root routine properly checks that the square root
exists. (What happens when a non-quadratic residue is square rooted by
exponentiation or the p=5 (mod 8) method may be exploitable. Yes,
after dividing by i it's a point on the twist, but I don't think
that's what comes out of the formula. And then the addition formulas
aren't right for the twist, so I don't know how to exploit the result
or show it isn't exploitable. However, it's a barrier to exploitation
in any case)

The big advantage of Montgomery coordinates is that they eliminate
entirely validation, so this is a non-issue for ECDH. Sadly, we can't
do signatures with them in a reasonable way, so we're stuck with a
step that might get skipped and cause vulnerabilities when skipped.

>
> In any case, this is (as you say) about the coordinates, not the curve.
> However, changing coordinates can change the corresponding curve constant,
> but when p == 3 mod 4 small constants will remain small irrespective of the
> coordinate system.
>
>
> An isogeny is a bit more than just a change in coordinates, but I agree that
> it’s reasonable to pick a curve structure, and later discuss which isogenous
> or isomorphic curves and which coordinates should be used for which
> protocols.
>
> I don’t think everyone on this list would agree with the above statement,
> though.  A pretty big part of Benjamin Black’s argument against \w+25519 is
> the idea that they are different curves, not just different coordinates for
> the same curve, even though the curves are isomorphic and not just
> isogenous.dd
>
> This is also why I listed “Curves isogenous to NUMS” as a separate candidate
> from NUMS in the “current candidates” email.

This email, along with the "Curve, Coordinates and Computations" email
is required reading for anyone who wants to understand the issues.
Sadly, I can't find it in my inbox.

Sincerely,
Watson Ladd

>
> Cheers,
> Craig
>
>
> Peace,
> — Mike
>
>
>



--
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin


-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin