[PATCH] ecc: Add Curve448.

[Daniel Kahn Gillmor]

On Thu 2019-09-26 18:19:23 +0900, Niibe Yutaka wrote:
> In RFC8410, (IIUC), an OID is assigned to an algorithm (signature
> algorithm, or key-agreement algorithm).  It doesn not represent
> a curve.  That's my understanding.  Please correct if I am wrong.

I believe this is correct.

> The name change is needed, I suppose, because key for ECDH and ECDH
> packet in OpenPGP will be in big-endian, if we follow the existing way
> with ECC curves (NIST ones, Brainpool ones, and Curve25519).  Note that
> for Curve25519, it is not in native format of X25519.  So, I intend that
> it will be same, that is, it will not be in native format of X448.

I'm not convinced that this kind of consistency is the right way to go.

In the world beyond gcrypt, points on goldilocks (curve 448) and curve
25519 have canonical a bytestring representation used by every other
implementation.  Requiring consistency *within* gcrypt between 25519 and
448 means requiring inconsistency between gcrypt and the larger world
for 448.  I'd rather see gcrypt use the standard representations for
as many points as possible.

> It is also possible to introduce new thing for X448.  We can define X448
> key and ECDH with X448 in OpenPGP, in the native format of X448.
>
> I can change the patch accordingly, if the latter is preferred.

I lean toward using the "native" format where possible, even if that
leaves 25519 as an outlier.

       --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/20190930/06eb1c8f/attachment.sig>