Subject: [Cfrg] New names for draft-ladd-safecurves

From: Watson Ladd <[email-masked]>
Date: Mon, 20 Jan 2014 19:17:25 -0800

I am proposing that we name the curves with the following scheme: E,
M, TE, indicating
the curve type, followed by a prime designator. The prime designator
will be the concatination
of the numbers a and b such that 2^a-b=p if such a and b exist and are
small. Otherwise I'll think of something (Ed448 Goldilocks I'm looking
at you).

Any objections? Or do we have consensus on this change, and I was just
to dense to notice?

A new version with significant alterations will be hitting the draft
server in a few days.

Sincerely,
Watson Ladd

---

From: Jon Callas <[email-masked]>
Date: Mon, 20 Jan 2014 19:50:12 -0800

> A new version with significant alterations will be hitting the draft

I think it's overkill, myself.

Really, there's no reason to designate in the name an Edwards curve from a Montgomery, especially because in the implementation someone's probably going to flip between representations. Only us math weenies really care about the representation, and you're going to confuse the coders.

I spent time talking to Dan and Tanja this weekend at ShmooCon about this sort of thing and I think that our agreement was that names like "Curve 255-19" (which covers both Curve25519 and Ed25519) or "Curve 414-17" (for the curve formerly known as Curve3617) made sense.

	Jon

---

From: Watson Ladd <[email-masked]>
Date: Mon, 20 Jan 2014 19:54:11 -0800

> Really, there's no reason to designate in the name an Edwards curve from a Montgomery, especially because in the implementation someone's probably going to flip between representations. Only us mat…

If I hand you a string of bytes, what point does that represent and on
what curve does it fall? Seems to me like that's a representation
issue we should all care about.

> I spent time talking to Dan and Tanja this weekend at ShmooCon about this sort of thing and I think that our agreement was that names like "Curve 255-19" (which covers both Curve25519 and Ed25519)…

This would be great except that we want both Edwards and Montgomery
wire formats. If there is consensus on only Edwards wire formats, that
naming will work fine.

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

---

From: Jon Callas <[email-masked]>
Date: Mon, 20 Jan 2014 20:11:52 -0800

> issue we should all care about.

I think that's *the* issue we should care about.

> wire formats. If there is consensus on only Edwards wire formats, that

Is the name the right place to solve this?

That's not rhetorical, I'm genuinely asking. If you give me a short description of how you'd handle it, I'm liable to just say, "Oh, yeah."

	Jon

---

From: Mike Hamburg <[email-masked]>
Date: Mon, 20 Jan 2014 20:12:39 -0800

> issue we should all care about.

It may depend on whether we expect a curve to be used for both signatures and ECDH, or just one purpose.  If they're only for one thing, then the letters make a difference.

I think Jon wants to use each curve for both purposes, at least potentially, which makes sense to me.  This is why I suggested always using the Montgomery point representation (or even its inverse square root! but maybe that's crazy) even for the Edwards curves.

I suppose in that case we should be using curves with a small A or (A-2)/4 in Montgomery form instead of small d in Edwards form, because you need to multiply by A more often: Edwards representations are probably fastest with Niels+Extended coordinates at that size so they almost never multiply by d.

>> I spent time talking to Dan and Tanja this weekend at ShmooCon about this sort of thing and I think that our agreement was that names like "Curve 255-19" (which covers both Curve25519 and Ed25519)…

This is also nice because you could call Ed448-Goldilocks as "Curve 448-224-1".

> wire formats. If there is consensus on only Edwards wire formats, that

If you're going to pick one, it should be Montgomery.  This is because the Montgomery ladder suffers almost a 10% hit from conversion, but Edwards suffers like an 0.2% hit.

-- Mike

---

From: Robert Ransom <[email-masked]>
Date: Mon, 20 Jan 2014 20:25:23 -0800

On 1/20/14, Mike Hamburg <[email-masked]> wrote:

> I suppose in that case we should be using curves with a small A or (A-2)/4
> in Montgomery form instead of small d in Edwards form, because you need to
> multiply by A more often: Edwards representations are probably fastest with
> Niels+Extended coordinates at that size so they almost never multiply by d.

The Montgomery-form ladder is as efficient for small-integer
Edwards-form d as it is for small-integer Montgomery-form parameter
((A-2)/4 or (A+2)/4).

Robert Ransom

---

From: Watson Ladd <[email-masked]>
Date: Mon, 20 Jan 2014 20:36:55 -0800

> Edwards-form d as it is for small-integer Montgomery-form parameter

Maybe it's because it's late, but I don't immediately see why
A=2(1+d)/(1-d) for a small integer d leads
to a fast multiplication in the Montgomery-form ladder. The best
solution I could come up with involves
multiplications by 3 small integers instead of 1. So maybe the
efficiency loss is small, but it still exists.

I also don't see why if you are going to toss in the y coordinate into
Montgomery form to disambiguate addition you
would use the Montgomery form as a wire format instead of Edwards
form. I'm aware you can recalculate the y coordinate
given the original one after a Montgomery ladder, but with radix-k
addition algorithms on Edwards this doesn't seem to be a win.

Maybe Montgomery form is just a red herring, but when I think about
the consequences of a missing square root check in an Edwards
form implementation for ECDH, I feel Montgomery form has a place here.

Sincerely,
Watson

---

From: Mike Hamburg <[email-masked]>
Date: Mon, 20 Jan 2014 20:38:56 -0800

> Edwards-form d as it is for small-integer Montgomery-form parameter

So it is.  Do you have a reference for that, BTW?  I derived it as:

x' = (x^2-z^2)^2
z' = 4xz(x^2 + Axz + z^2)

These are typically computed from (x+z)^2 and (x-z)^2, with 4xz being the difference between the two.

Substituting A = 2(1+d)/(1-d) = 4/(1-d)-2, we have

z' = 4xz(x^2 - 2xz + z^2 + 4xz/(1-d))

Scaling both x' and z' by (1-d) gives

x' = (x+z)^2 (x-z)^2 (1-d)
z' = 4xz(4xz + (1-d)(x-z)^2)

requiring the same 2 bigmuls, one smallmul and one add that the standard formula requires.

-- Mike

---

From: Robert Ransom <[email-masked]>
Date: Mon, 20 Jan 2014 20:54:53 -0800

> So it is.  Do you have a reference for that, BTW?

I don't have a reference for it.  (But I did use it in my Curve1174
implementation last summer, and I'm pretty sure I said it a few days
ago on this list.)

<http://hyperelliptic.org/EFD/g1p/data/twisted/coordinates> gives an
isomorphism to Montgomery form with A = 4a/(a-d) - 2; the parameter
for the formulas given on
<http://hyperelliptic.org/EFD/g1p/auto-montgom-xz.html> is a24 =
(A+2)/4 = a/(a-d).  So the fact that when d is a small integer (and a
is 1 or -1, as usual), the Montgomery-form parameter is the reciprocal
of a small integer is fairly obvious from that.

The remaining step is to move the multiplication by 1/a24 into BB.

Robert Ransom

---

From: Robert Ransom <[email-masked]>
Date: Mon, 20 Jan 2014 21:06:53 -0800

> form implementation for ECDH, I feel Montgomery form has a place here.

I would suggest using the Montgomery-form x coordinate with the sign
bit of the Edwards-form x coordinate.  (In fact, I *did* suggest that:
<http://www.ietf.org/mail-archive/web/cfrg/current/msg03868.html>
<http://www.ietf.org/mail-archive/web/cfrg/current/msg03870.html>)

And yes, the Brier-Joye formulas to recover Montgomery-form y after
the Montgomery ladder would be faster than Brauer's algorithm on
Edwards-form points for variable-base single-scalar multiplication.

Robert Ransom

---

From: Robert Ransom <[email-masked]>
Date: Mon, 20 Jan 2014 21:11:53 -0800

> The remaining step is to move the multiplication by 1/a24 into BB.

Er.  Move the multiplication by 1/a24 into BB *after* BB is used in
calculating E.

Robert Ransom

---

From: Mike Hamburg <[email-masked]>
Date: Mon, 20 Jan 2014 21:41:39 -0800

> <http://www.ietf.org/mail-archive/web/cfrg/current/msg03870.html>)

Amusingly, if you say that "sign" is "Jacobi symbol" (when p==3 mod 4), the two are the same for q-torsion points.  But either way, the difference is a couple of field muls vs a slightly messier spec.

> Edwards-form points for variable-base single-scalar multiplication.

Is this still true for large curves?  I don't think it's true asymptotically, and if people switch from inverse-by-exp to inverse-by-blind-and-EGCD, then you lose your free square root and the tradeoff might happen before 521 bits.  You might get your freebie back again if you spec that sign is Jacobi symbol and use a blind EGCD inverse-and-Jacobi-symbol, but again this only works for p==3 mod 4.

Cheers,
-- Mike

---

From: Robert Ransom <[email-masked]>
Date: Mon, 20 Jan 2014 22:44:34 -0800

On 1/20/14, Mike Hamburg <[email-masked]> wrote:
> Amusingly, if you say that "sign" is "Jacobi symbol" (when p==3 mod 4), the
> two are the same for q-torsion points.  But either way, the difference is a
> couple of field muls vs a slightly messier spec.

The least significant bit of the least positive residue is easier to
compute during point compression, and is well-defined regardless of
the field order, so I would use that instead.

> Is this still true for large curves?  I don't think it's true
> asymptotically, and if people switch from inverse-by-exp to
> inverse-by-blind-and-EGCD, then you lose your free square root and the
> tradeoff might happen before 521 bits.  You might get your freebie back
> again if you spec that sign is Jacobi symbol and use a blind EGCD
> inverse-and-Jacobi-symbol, but again this only works for p==3 mod 4.

The Montgomery-form ladder takes 5M+4S+1*param+... per scalar bit.

Edwards-form Brauer (assuming a=-1) takes 3M+4S+... per doubling, and
1M (conversion to extended coordinates) + 7M+... (madd-2008-hwcd-4;
assuming the table is affine) per scalar limb, so it could (just
barely, counting multiplications only) appear to break even using
4-bit limbs.  But the table precomputation for that includes multiple
point additions and an inversion, and each 4-bit scalar limb requires
a constant-time lookup from a 7-element table, so even asymptotically,
you're eaten by overhead.

Robert Ransom

---

From: Mike Hamburg <[email-masked]>
Date: Tue, 21 Jan 2014 00:29:08 -0800

> the field order, so I would use that instead.

Yeah, I love the Jacobi thing because it's a cool trick, but I still think the low bit is probably better for these reasons.

> you're eaten by overhead.

For practical purposes, you're right: it's probably at most a wash even at longer bit lengths.

I actually measured it for a 252-bit prime, 250-bit curve by microbenching some old code.  I measured a constant-time Edwards scalar multiply (no conversion to/from affine) vs a constant-time Montgomery scalar multiply (start in affine, but no conversion back to affine at the end). The result was pretty close, within the margin of error of the benchmark on Sandy Bridge.

The code is using "extensible coordinates" for the accumulating point (a lazy man's version of Hisil et al's extended with lookahead, which would give the same result) and gives you that 8M/add without putting the table in affine (it's in "projective half-Niels coordinates", i.e. 4-coordinate readd form).

Otherwise your math is fine.  You're trading off a constant-time lookup in a big table every k bits, and some precomputation (slightly cheaper than the lookups) in the Edwards version vs a conditional swap every bit, a multiplication by a small number and a couple of extra additions for the Montgomery ladder.

After about 300 bits, extrapolation suggests that a 5-bit window should be faster than a 4-bit one, if only marginally.  All in all, by 448 bits (extrapolating to Ed448-Goldilocks timing measurements) the Edwards implementation is maybe half a multiply per bit ahead of the Montgomery one, before compression and decompression are taken into account.

But then there's compression and decompression.  I'm pretty sure a Montgomery implementation can always use the inverse square root trick at worst, whereas Edwards always has to take a square root and a full inversion separately (to decompress and to compress, respectively).  I don't have a timing for blind-and-EGCD on me.  Maybe it's half a mul per bit, and then the whole thing is a wash.  Maybe it's 0.3, and that giant pile of complexity and memory thrashing bought you a 2% win.  Woo.

So Montgomery is the better choice on Sandy Bridge out to 448 bits and probably to 521 as well.

Cheers,
-- Mike

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 21 Jan 2014 16:28:55 +0100

Jon Callas <[email-masked]>:

I spent time talking to Dan and Tanja this weekend at ShmooCon about this
> sort of thing and I think that our agreement was that names like "Curve
> 255-19" (which covers both Curve25519 and Ed25519) or "Curve 414-17" (for
> the curve formerly known as Curve3617) made sense.

Yes, it does. This would fix the single major flaw of Curve25519 --
concatenating base-10 numbers to spell out a tuple just doesn't make sense
(except as a trap, so that if anyone reads it out as "twenty-five thousand
..." you'll know they don't know what they're saying).  I also don't really
like having whitespace in those names, so I'd prefer "Curve-255-19" over
"Curve 255-19".

("Curve" isn't very descriptive, but I've yet to see a more descriptive
name for this curve that is actually helpful.)

Bodo

---

From: Watson Ladd <[email-masked]>
Date: Tue, 21 Jan 2014 08:33:38 -0800

>> the curve formerly known as Curve3617) made sense.

My one concern which I've stated before is that we would then need a
single wire format for Curve25519 and Ed25519.
Robert Ransom's idea (sorry for the hijack) is the following: Suppose
Bv^2=u^3+Au^2+u is isogenous to ax^2+y^2=1+dx^2y^2, with the isogenies
u=(1+y)/(1-y), v=(1+y)/(1-y)x=ux. Then we represent points as u and
the sign of x.

A=2(a+d)/(a-d)
B=4/(a-d).

An implementation using the Montgomery ladder to multiply proceeds as
usual, using the fact that A is the reciprocal of a small integer
to rewrite the equations. It then reconstructs v (there is a fast
formula), and uses that to compute the sign of x. One using the
Edwards curves proceeds as usual, then inverts the isogeny to get u,
and uses x to get the sign bit.
The argument for this is we can specify all our curves in twisted
Edwards form with d small, a=+/-1, and life is nice for everyone.
Unfortunately Curve25519 doesn't fit this nice pattern, and people
want to use that exact curve. This form also involves a bit of extra
field math for everyone, even if they are all going to do ECDH or
Edwards addition afterwards, and so will want that form anyway. There
is also a problem of exceptional cases if a and d are nonsquares
modulo p for example.

Have I rendered correctly the arguments for and against?
> ("Curve" isn't very descriptive, but I've yet to see a more descriptive name
> for this curve that is actually helpful.)

NIST isn't useful either as a prefix, but we live with it.
Anyway, my view is whatever people want to call these they can call
them, bobo and kiki aside.
>
> Bodo
>
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Paul Lambert <[email-masked]>
Date: Tue, 21 Jan 2014 10:30:41 -0800

>>> the curve formerly known as Curve3617) made sense.

Two names would be better to differentiate between a Edwards or Montgomery
based point representation for the same curve.

WE also are working on the assumption that there are just one curve choice
for a particular field size. We should provide a extensible naming scheme
that would allow the later introduction additional options (e.g. Ed255
would be #1 of that size and flavor).

Paul 

>>name

---

From: Watson Ladd <[email-masked]>
Date: Tue, 21 Jan 2014 10:34:44 -0800

> would be #1 of that size and flavor).
Why would we need these other options? If you have a new curve it needs to
look different to have a speed advantage. The security picture for ECC has
been stable for decades now.

---

From: Paul Lambert <[email-masked]>
Date: Tue, 21 Jan 2014 12:06:44 -0800

On Jan 21, 2014 10:30 AM, "Paul Lambert" <[email-masked]<mailto:[email-masked]>> wrote:
>
>
>
> On 1/21/14, 8:33 AM, "Watson Ladd" <[email-masked]<mailto:[email-masked]>> wrote:
>
> >On Tue, Jan 21, 2014 at 7:28 AM, Bodo Moeller <[email-masked]<mailto:[email-masked]>> wrote:
> >> Jon Callas <[email-masked]<mailto:[email-masked]>>:
> >>
Why would we need these other options? If you have a new curve it needs to look different to have a speed advantage. The security picture for ECC has been stable for decades now.

Your particular metrics for speed may not always the primary consideration for a system design. We should not be limiting diversity.

Clearing having two names for the Montgomery and Twisted Edwards version of a 'curve set' facilities the description of the processing and gives clarity in the point representation sent over a protocol.

Paul

> >> [email-masked]<mailto:[email-masked]>
> >[email-masked]<mailto:[email-masked]>

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Tue, 21 Jan 2014 21:54:30 +0100

> would be #1 of that size and flavor).
How about something like curve-255-19-m1 and curve-255-19-e1 for Montgomery and
Edwards form, respectively? m/e is for the type, and "1" is here as a hint that
they're not the only (secure) curves over this field.

Or, more in line with the existing names:
- curve255m1 (just the field size)
- curvep255m1 (same, with a p for "prime field").

Manuel.

---

From: Jon Callas <[email-masked]>
Date: Tue, 21 Jan 2014 18:16:18 -0800

My concern is essentially this:

Assume a curve that we'll call 1234-56 for some reason. If it's a nominally Edwards curve (like 414-19, fka Curve3617), it can (and will) appear in Edwards, twisted Edwards, and Montgomery forms. There are lots of good reasons for flopping it around and doing arcane things with it.

On the one hand, one might want to transport the curve in any of those formats. The primary purpose of a standard is for interoperability. Thus, having a way to know what form a curve is transported in is a good idea.

On the other hand, having many names for things causes questions and confusion because you then have to explain why the different names are really the same thing. Elliptic curves are hard enough as it is.

On the third hand, it might even be good to have a single *transport* format and just pick one. Force people to transport in one format.

On the fourth hand, is that *really* going to cause less confusion than having a name for each format?

See -- I don't have an answer here. With my standards hat on, I tend towards the third hand. Define *a* transport format and have just one. With my crypto hat on, some crypto people would cheer that, and others wouldn't. Either way, there's chance for error.

	Jon

---

From: Watson Ladd <[email-masked]>
Date: Tue, 21 Jan 2014 21:12:56 -0800

On Tue, Jan 21, 2014 at 6:16 PM, Jon Callas <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

Let me reduce the number of hands you have to deal with.

> Assume a curve that we'll call 1234-56 for some reason. If it's a nominally Edwards curve (like 414-19, fka Curve3617), it can (and will) appear in Edwards, twisted Edwards, and Montgomery forms. T…

Not our problem: if an implementation does something arcane, and it
gets the right answer, it isn't a problem if our standard doesn't
explain what it does. The issue would be if protocols were likely to
do arcane things, and it was useful to put them in this draft as well.

> On the other hand, having many names for things causes questions and confusion because you then have to explain why the different names are really the same thing. Elliptic curves are hard enough as…

Not the same, isomorphic. Ed25519 isn't the same as Curve25519, they
are isomorphic curves. Does it matter to implementors if they are
isomorphic or not? Not really: the formulas work, and those who get it
can take advantage of that fact.

> On the third hand, it might even be good to have a single *transport* format and just pick one. Force people to transport in one format.

Currently my idea is each curve name has a specified format. How is
this confusing?

> See -- I don't have an answer here. With my standards hat on, I tend towards the third hand. Define *a* transport format and have just one. With my crypto hat on, some crypto people would cheer tha…

Here is the problem in a nutshell: some protocols can get away with
transporting only an x-coordinate, and some cannot. For those that
can,
Montgomery ladders naturally work on the twist as well as on the
original curve, so there is no issue with a missing check causing
problems.

However, if the transport format requires a y coordinate, than
Montgomery ladder implementations have to do some extra work to
transmit. The extra work isn't prohibitive, but given that we aren't
adding points, it seems a bit useless to do that work.

We've already crossed the Rubicon when we decided not everything was a
short Weierstrass curve. The zero, one, many rule still seems good to
me.

When an implementation uses an Edwards curve, it needs to reconstruct
points correctly. This is involves a check of being a quadratic
residue or the correct answer to a square root, which if missing isn't
an interop problem but a potential security issue for ECDH. However,
the extra bit for exact reconstruction is free when packing.

With signature schemes the natural approach is to use Edwards curves
and take full advantage of batching. This can't be done with
Montgomery ladder, and as the exponents (except for the signature
creation exponent) are public (well, random, but revealing them after
you start can't hurt you) Edwards curves can use Bos-Coster algorithm
for very high verification speed. Forcing an Edwards curve to pack to
Montgomery form is a waste of time, given that the receiver is going
to be using Edwards form anyway.

I've not seen a strong argument for using a unique form per
isomorphism class. ECDH can work on Edwards curves if implementation
size is an issue. Robert Ransom argues that as small Edwards d leads
to fast Montgomery arithmetic, we should specify only Edwards curves,
and the equivalent Montgomery form, but he wants a single point format
that requires reconstructing y for a Montgomery ladder and turning
points into Montgomery points. (Ask him why it makes sense: I
disagree).

For a protocol like MQV, Edwards form would still make sense.
Implementations could use the Montgomery ladder and reconstruction for
the single-exponents, and take full advantage of Shamir's trick on an
Edwards curve for the final key. But MQV isn't used because of
patents, and it isn't that useful. I don't see a reason to expand the
draft's scope to support this niche case with an implementation
strategy that isn't strictly necessary.

Hopefully this explains my position and the issues more clearly then
my prior emails.
Sincerely,
Watson Ladd
>
>         Jon
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Universal 3.2.0 (Build 1672)
> Charset: us-ascii
>
> wj8DBQFS3yn0sTedWZOD3gYRAnx2AJ4q3SrQ7/eeTUYgwAYnZNLfncOg6wCfWRy5
> EvQ+uaBNA2SjnJFLcasiYlg=
> =XuJM
> -----END PGP SIGNATURE-----

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 22 Jan 2014 10:22:29 +0100

> NIST isn't useful either as a prefix, but we live with it.

I'm fine with "Curve-255-19" (plus possibly a postfix) given that
"Curve25519" is a reasonably well-known and reasonably unique name in the
research literature, but I think that "Curve" is much worse a prefix than
"NIST".  While the latter also doesn't tell you anything specific about a
given curve, at least it tells you who assigned that name, whereas "Curve"
is more of a generic honorific than an actual name (curves without "Curve"
in their name are curves just as much as the others).

---

From: Watson Ladd <[email-masked]>
Date: Wed, 22 Jan 2014 08:10:41 -0800

> in their name are curves just as much as the others).

So let's drop curve and replace with E, M, or TE to represent the
shape. For the possible generations
(which would support code size reductions with multiple curves over
the same primes) we could use m1,m2 etc.

My alternative is  g1p255-19m486662. g1p indicates genus 1 over a
prime field, 255-19 designates the prime, m486662 indicates
that is the montgomery curve with constant 486662. The problem with
this naming scheme is that it involves remembering a bunch of
constants.

Honestly, if someone could suggest a good naming scheme, I'm all ears.
But names aren't that important: the discussion over encoding formats
is much more important. Using the Safecurves names doesn't appear to
have anything wrong with it, and ends this stupid bikeshedding.
Sincerely,
Watson Ladd

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 22 Jan 2014 17:30:16 +0100

That's why I said that I'm fine with using something like "Curve-255-19"
(plus a prefix).

---

From: Paul Lambert <[email-masked]>
Date: Wed, 22 Jan 2014 11:14:09 -0800

>Honestly, if someone could suggest a good naming scheme, I'm all ears.

I¹m skeptical about the size of your ears, but here is some text suitable
for an RFC on the topic of curve identifiers for the clear naming and
identification of elliptic curves (attached below).

Paul

- - - - - -

Curve Identifiers

Curve identifiers are uniquely identify a class of elliptic curves and a
specific set of domain parameters for the curve type.

The first two characters of the curve identifier represent the curve type:
   mo - Montgomery curve
   ed - Edwards curve
   te - Twisted Edwards curve
   sm - Small Weierstrass curve

The third character of the identifier describes the field type:
   P - prime field Fp
   T - binary field F2m

The digits (usually 3) following the field type represent the order of the
field base 2 (255 for p = 2^255-19).

Following the field size digits, characters and digits are used to
indicate origin and version of the parameters.  Where a set of isogenous
curves are described these characters should be the same for each of the
related parameter sets.

- - -   end text - - -

Example entry for inclusion in a catalog for the documentation and
categorization of elliptic curves for use in Internet protocols.

- - -  catalog entry - - -

    curveId = ŒmoP521s1¹    # also known as ŒM521¹
    strength = 259
    oid = None
    p  = 2**521-1
    d  = -376014
    xG = 
0x752cb45c48648b189df90cb2296b2878a3bfd9f42fc6c818ec8bf3c9c0c62039\
           
13f6ecc5ccc72434b1ae949d568fc99c6059d0fb13364838aa302a940a2f19ba6c
    yG = 12
    order  = 2**519 - 3375547632585017057891076304187826360719\
                      04961214051226618635150085779108655765
    order = 
0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\
              
fd15b6c64746fc85f736b8af5e7ec53f04fbd8c4569a8f1f4540ea2435f5180d6b
    cofactor = 4

[B1] Diego F. Aranha, Paulo Barreto, Geovandro Pereira and Jefferson E.
Ricardini, "A note on high-security general-purpose elliptic curves²,
http://eprint.iacr.org/2013/647.pdf, 2012.

- - -    - - -