[PATCH] ecc: Add Curve448.

[Daniel Kahn Gillmor]

On Thu 2019-10-03 15:39:46 +0900, NIIBE Yutaka wrote:
> Hello, again,
>
> Thanks for your suggestions.
>
> Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
>> I'm not convinced that this kind of consistency is the right way to go.
>
> I see your point.  If I could allow to make an excuse, my initial
> motivation was minimizing the patch.
>
> Anyway, I concur.
>
> Thus, considering again, I'm going to modify my patch to use native
> format of X448 to represent point (with the prefix 0x40), using OID of
> X448.
>
> Probably, for libgcrypt, I'll introduce new internal flag,
>
>     ECC_DIALECT_LITTLE_ENDIAN
>
> to express that the curve prefers/requires non-default serialization
> format (from the view point of existing curves of libgcrypt).  Then,
> code paths will be more cleaner.

It occurs to me that if we want consistency within some future version
of gcrypt, we could introduce the same codepath for 25519 in its native
representation -- so that the invoker could use either representation.
Then we could somehow deprecate the older representation, and finally
remove it on the next major API break.

I'm not sure how to do that deprecation and removal effectively and
safely, given gcrypt's string-driven interface, but if anyone with
deeper understanding of gcrypt's API design and evolution wants to
suggest a deprecation mechanism, i'd be happy to review it.

> Well, it reminds me about a virtue of good baseball umpire;
> Don't keep further misjudgments for your own consistency.
> Or, I whould quote a phrase in Chapter I of the first book of Confucius.

:)

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20191003/a9c1188b/attachment.sig>