Fwd: How to use a named elliptic curve?

I had meant this reply to go to the list not only Jan.

---------- Forwarded message ---------
From: John Cremona <john.cremona@gmail.com>
Date: Sun, 10 Jan 2021, 13:22
Subject: Re: How to use a named elliptic curve?
To: Ján Jančár <johny@neuromancer.sk>

On Sat, 9 Jan 2021, 18:00 Ján Jančár, <johny@neuromancer.sk> wrote:

On 09/01/2021 12:36, Bill Allombert wrote:
> On Wed, Jan 06, 2021 at 03:38:33PM +0100, Ján Jančár wrote:
>> Hey all,
>>
>> On 02/01/2021 12:00, Jeffrey Walton wrote:
>>> On Sat, Jan 2, 2021 at 5:08 AM Karim Belabas
>>> <Karim.Belabas@math.u-bordeaux.fr> wrote:
>>>>
>>>> * Jeffrey Walton [2021-01-02 05:58]:
>>>>> Hi Everyone,
>>>>>
>>>>> I'm working through the elliptic curve tutorial at
>>>>> https://pari.math.u-bordeaux.fr/Events/PARI2017c/talks/ecc_en.pdf. I
>>>>> want to use a named curve, like secp256k1 or secp256r1. It does not
>>>>> appear to be covered in the tutorial.
>>>>> ...
>>>>> How do I create a named curve?
>>>>
>>>> The named curves mechanism only supports Cremona labels at this point
>>>> (for curves over Q sorted by conductor provided by the Cremona database,
>>>> which we repackage as 'elldata'); with the second syntax as in
>>>>
>>>> E = ellinit("36a1");
>>>>
>>>> None of the crypto curves names (SEC2, FIPS 186-4, RFC3279, etc.) are
>>>> currently supported by this mechanism. It's an interesting option,
>>>> though, that would not be hard to support: Crenoma labels start by a
>>>> digit, all crypto curves names I am aware of start by a letter...
>>>>
>>>> What names would we need to support ?
>>>> - [PKR]-* from FIPS
>>>> - sec* from SEC2
>>>> - prime* from RFC
>>>
>>> curve25519 and curve448 are fairly popular. SEC-2/NIST and Bernstein's
>>> curve would probably keep most people happy.
>>>
>>> The RFC 3279 curves may be useful, too. I seem to recall some of them
>>> are considered weak/wounded. I think some of them were from the 1998
>>> version of ANSI 9.62. They include c2pnb163v1 and wtls1. But they
>>> would probably make good academic material.
>>
>> I co-created and maintain a repository of standard elliptic curves
>> used in cryptography at: https://neuromancer.sk/std/ and https://github.com/J08nY/std-curves.
>> The curves are available in JSON and the website provides SAGE code
>> that instantiates the curve, see for example: https://neuromancer.sk/std/secg/secp256r1.
>> I could add functionality that creates and displays PARI-GP code that instantiates
>> the curves as well.
>>
>> I would otherwise be against directly including somewhat standard elliptic curves
>> in the PARI codebase, even though its not really my call, simply because of the large
>> amount of them and the hardness of saying what is really "standard" or "interesting".
>>
>> Perhaps there can be a PARI script distributed that understands the kind of JSON format
>> we use in the std-curves repository or downloads them directly from github?
>
> It would likely be much simpler to convert std-curves to PARI format
> once, and put that for downloads instead.
>

I just had a look on the format of pari-elldata and also the original Cremona's database
at https://github.com/JohnCremona/ecdata and the format does not seem to include a way
to define the base field of the curve, all the curves are assumed to be over the rationals.

My ecnf-data repo has some elliptic curves over number fields. When I first made the paridata files for curves over Q, I discussed the format with pari developers and then wrote a script to rewrite the required data in that format.

So to support standard elliptic curves this functionality/format would have to be extended
to allow for specification of the base field (usually a prime field or a binary extension
field with polynomial basis with a chosen generator polynomial).

Cheers,
--
Jan