Some interesting observations:
1. Curves over both prime fields and characteristic 2 fields are included.
2. There are no curves over a field of characteristic 2 with a composite power
(F2**m, with m composite).
3. Koblitz curves are included.
Thanks Don. It certainly adds a nice stamp
There are 2 formats, ascii and postscript.
The postscript form has a lot of explanation,
the ascii is just the curve data.
Patience, persistence, truth,
The postscript file also gives an (approximate) security level appropriateness
of the curves to various symmetric key sizes.
All in all, good stuff.
>Yes, perhaps the most interesting thing is that this can be seen as an
>endorsement of the security of ECC (at least for the curves provided) by an
>agency of the US government.
Of course if you are paranoid, this means that these are the curves for
which they have found a crack. But of course none of us is paranoid.
Also, the random curves should help alleviate some fears. I am sure all the
published curves will be studied.
And the random curves would present an interesting question to someone trying
to create a random weak curve. Namely, how prevalent can a (otherwise
unknown) "weak" curve be and still be found via a random seed? If it is too
rare, it is difficult to find using a seed, if it is too common, it will likely
be discovered by someone else.
>There are 2 formats, ascii and postscript.
>The postscript form has a lot of explanation,
>the ascii is just the curve data.
Thanks for the info: since I find postscript somewhat awkward to read,
I hesitated to download it. Now I'll take the time to deal with this.
John Savard ( teneerf<- )
And thats the problem....
These curves are generated by passing a random seed S through a one-way
process which creates the B parameter for the curve y^2=x^3-3x+B mod p. (I
am talking about the GF(p) curves but my remarks apply to GF(2^m) as well.).
Where the random seed S came from, nobody knows.
Now if the idea is to increase our confidence that these curves are
therefore completely randomly selected from the vast number of possible
elliptic curves and hence likely to be secure, I think this process fails.
The underlying assumption is that the vast majority of curves are "good".
Consider now the possibility that one in a million of all curves have an
exploitable structure that "they" know about, but we don't.. Then "they"
simply generate a million random seeds until they find one that generates
one of "their" curves. Then they get us to use them. And remember the
standard paranoia assumptions apply - "they" have computing power way beyond
what we can muster. So maybe that could be 1 billion.
A much simpler approach would generate more trust. Simply select B as an
integer formed from the maximum number of digits of pi that provide a number
B which is less that p.Then keep incrementing B until the number of points
on the curve is prime. Such a curve will be accepted as "random" as all
would accept that the decimal digits of pi have no unfortunate interaction
with elliptic curves. We would all accept that such a curve had not been
So, sigh, why didn't they do it that way? Do they want to be distrusted?
Fastest is best. MIRACL multiprecision C/C++ library for big number
> Don Johnson
>So, sigh, why didn't they do it that way? Do they want to be distrusted?
I suppose they feel that they are not distrusted, and therefore are
free to select optimal curves, just as the S-boxes in DES were
optimal, rather than being generated from pi or something. One notes
that many of the AES candidates had their S-boxes generated in ways
that were intended to show that nothing funny was going on.
And, although the basic idea of using elliptic curves
cryptographically is not patented, there are patents covering the
efficient algorithms that are used in practice to implement ECC.
Which shows that NIST is not averse to using patented technology,
_when doing so is indicated by the state of the market_.