Re: [Cfrg] draft-ladd-safecurves-02

Watson Ladd <> Sat, 11 January 2014 01:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CAA431AD935 for <>; Fri, 10 Jan 2014 17:01:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3-93HIviGyqe for <>; Fri, 10 Jan 2014 17:01:12 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c00::22c]) by (Postfix) with ESMTP id 4C0BD1ACCE5 for <>; Fri, 10 Jan 2014 17:01:12 -0800 (PST)
Received: by with SMTP id l18so3763494wgh.11 for <>; Fri, 10 Jan 2014 17:01:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=U2jBqw/8A/DiqRqjGpGUG6zwLvidlLZHTt+x3sgcP0Q=; b=b5poUc9rWsQ1A14wVrgD1EqF+rlw13jQaWnrcuos1Vx0UVRTm9WiFPslLvnkypdIa+ ZKJnCOGjhyt8FokrTau/nE4/VeNmgDglM032BiGIn/2vzt1Dri/mOjk6Z9uRjoYm1Q7l /1OaDRTlfLaGT9FA9uDgsRxRKSl8vbXZpoS1gUOsUZMcwMHCJn58FECb3d2KducIx8r+ qB6FCCdwX2TePTWhw4/o7CBVpKnY2WpY0f2Sf3VlsRNDPqw6WA+ZXoHbmU4BQxsTuNoS tlIoW+0WbwW+upojoN69bJ8OSEbJkqHoU872TIVKCNe2FWCmKa0QVF2pfrwaVA1aVPuY sxSg==
MIME-Version: 1.0
X-Received: by with SMTP id ub15mr5212084wib.44.1389402061568; Fri, 10 Jan 2014 17:01:01 -0800 (PST)
Received: by with HTTP; Fri, 10 Jan 2014 17:01:01 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Fri, 10 Jan 2014 17:01:01 -0800
Message-ID: <>
From: Watson Ladd <>
To: Dan Brown <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [Cfrg] draft-ladd-safecurves-02
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: Sat, 11 Jan 2014 01:01:15 -0000

On Fri, Jan 10, 2014 at 4:37 PM, Dan Brown <> wrote:
> I didn't agree with all the arguments on the Safecurves URL, at least when I last read it a few months ago. Nor did I agree with all DJB said on the TLS WG list.
> I'm going to try to write up to CFRG my disagreements soon.

Do you believe these curves are insecure? Because people want to use
them. They pass every known criterion for ECC security.
Just because you don't like the rationale vs. P256 (massively higher
performance in software, better twist security) doesn't mean that
they aren't a valuable option to have, particularly if the suspicions
about the random seeds are verified.

Furthermore, are you objecting to the draft, or to DJB? Because one of
those is under discussion here.

> Maybe I'm old school, but I'd expect references to be stable and dated. Even if CFRG consensus (eg all minus me) fully agrees with the site today, the site could change, in a way not expected.

The rationale for picking a curve is not a normative feature of a
specification. However, validating that these numbers are prime
doesn't take that long. The twist order is the order of the curve with
a known adjustment, and so can be validated given only that the
cofactor and prime order are correct. The Hasse-Weil bound makes this
validation easy if you know what it is supposed to be. Safecurves only
contains a proof of primality open
to human verification. If you want, run RUNDOWN and stick the results
in here. But that would be a bit ridiculous.

If DJB and Tanja Lange publish Safecurves in a more stable form, we
could cite that. Or we could base64 the verification script and ram it
in an appendix. Or we could assume that everyone that paranoid has
PARI to do the work.

> The CFRG consensus may also be to move ahead with these curves, without agreeing fully with the site.

How is the current text in any way an endorsement of a website? This
concern is specious.

> So it might help for the spec to state the CFRG's rationale for accepting these curves.

Why would the CFRG have a shared rationale? Some people might like
efficiency, others the compact form of points, others the

> More practically, ideal would be to advise users of the advantages and disadvantages of these curves, over others.

More than the security considerations does now? Efficiency is
constantly changing as people optimize the heck out of one or another
thing, and so I don't feel like it belongs here. Security
considerations are I think well covered: the cofactor tradeoff is a
well-studied one, and can't bite that hard.

What advantages and disadvantages do you feel require additional
coverage? Why do you think this material belongs in this I-D?
> From: Watson Ladd
> Sent: Friday, January 10, 2014 6:31 PM
> To: Alyssa Rowan
> Cc:
> Subject: Re: [Cfrg] draft-ladd-safecurves-02
> On Fri, Jan 10, 2014 at 11:48 AM, Alyssa Rowan <> wrote:
>> Hash: SHA512
>> On 10/01/2014 19:11, Watson Ladd wrote:
>>> Added: explicit formulas and a point format (big endian with a bit
>>> for the missing coordinate).
>> Fair enough. (Cofactors were also added, by the way.)
>>> The name is now the Chicago curves.
>> As good as any other.
>> Comments:
>> • Typo in end of section one: Weierstrass, not Weierstrauss.
> Fixed
>> • I think it'd be a little more helpful if section 2 were split into
>> two sections: the Montgomery curves, and the Edwards curves. That'd
>> make it much more apparent which curves are applicable to which
>> sections in 3 and 4.
> I'll think about a clean way to do this. Of course, you can use
> isogenies to convert
> between all of these forms.
>> • Pretty please can we have Curve1174 as well?
> Included.
> Anymore suggestions? This next one it would be nice to get Last Call on.
>> Other than that, no more comments.
>> E-521's passed all tests, by the way, as expected (and it seems was
>> obviously rigid enough that three groups actually came up with the
>> exact same curve!).
>> I see no particular reason to hold this up.
>> - --
>> /akr
>> iQIcBAEBCgAGBQJS0E6JAAoJEOyEjtkWi2t6V3wP/0CHxxQtWozhfilM5BY+6Ffw
>> ER+Hmtl8La6OJ/cR0iAaP92PY9UScbUFzWPAJXOljGTPYH7D7dykdAUSnfN5vfy4
>> IeBdkJm66C/JYRwq20y3noSlQfJfclJYDOJIscUco6TYGV3/eLjiMFVFQfzAjJlz
>> RHDwYbr8Quc2lr4Hjl4mm+NRHFdUskhD4i7lA0DfcjohILxC4dw71f5wlmDehuMI
>> /MGccPbcPfQ0lEJpq5E3cY3jNtPU+EonY4TNnBA9mg2a2wVm2iIGOatptEzo+R7Q
>> fsjw+i2MXML+gNqpspGcA5RPU3x0DHSSzu5DDhpRH5V+So51mVdXFjGeLrLK1gJk
>> CZnOdDGgwc1tmOaphWMZZdcCYZosm8UMqh/J5tHCqUooknWxzVEKUs7eyn3TG6+I
>> +gdtbOdZhQf0K8iIXtwc874+G+e2c0MiU64GkNN3UT/7QFQY5zVxcgDLXwzUHcZk
>> PXx55n5IFz7iTwjTZd859grGRubHHjqDnnE/gNeWp7iGq2UezYMiRcLJUCehglYi
>> 72bAdbRc/bLOBoIHzJSuqEDR0TKRFmmrIN0pfSJe7PO9iun3b/rLIYavDfwH8dLN
>> NfKGARVJurKm1aW7wFk5
>> =PsP0
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> Cfrg mailing list
> --
> "Those who would give up Essential Liberty to purchase a little
> Temporary Safety deserve neither Liberty nor Safety."
> -- Benjamin Franklin
> _______________________________________________
> Cfrg mailing list
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

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