Smartcard EdDSA Support

Werner Koch wk at
Tue Mar 25 14:10:08 CET 2014

On Tue, 25 Mar 2014 08:43, gniibe at said:

> I have implemented the Twisted Edwards curve computation routine for
> Gnuk, and I am currently considering to integrate this routine.

Cool.  I was about to ask you for this.  For those who do not follow the
commits: I implemented ssh-ed25519 support for gpg-agent on Saturday.

> For (2), there are two ways, standard EdDSA representation
> (y-coordinate only + parity of x, little endian) or no-compression
> representation (big endian) which starts with 04.  It would be good to
> use no-compression representation, as it sounds more compatible.

I strongly in favor of the standard representation.  The only problem I
see is that it does not fit into the compression flag byte model.
Having exactly 32 bytes would really be nice but if it turns out that an
indicator byte would be helpful, we need to look into that.  I have not
looked at Simon's TLS I-D for Ed25519 but I recall that a new flag byte
value was discussed.  

A flag byte with the MSBit cleared would be helpful for implementers
because the key could be considered as any kind of number without
running into the sign problems (cf. ASN.1's octet-string vs. integer
trouble).  And the compression is actually part of the specification.
However, with a flag byte implementers would be free to do either of

This is actual the crucial part to get Ed25519 into OpenPGP.  I hoped
that Watson Ladd's I-D would soon be usable as a spec but it turned out
that he shifted his attention a bit to more general questions.  Thus we
may want to do our own thing and don't wait for the committee^WCFRG.

> For (3), it will be algorithm ID + OID.  (we need new algorithm ID for
> EdDSA.)  I'm not sure if we will have EdDSA with different curves in
> future, but if there is such a possibility, OID is required.

There is Curve41417 which is also an Edwards curve and I assume that
Bernstein and Lange developed it with EdDSA in mind.  I have not seen
the specs, though.

> No, I haven't tested the code on the target board yet.  It has been
> only tested on host.  I need to integrate it first, as the code is
> somewhat big.  Usually, I test code on the target board on RAM, but
> this time, it is bigger than 20kB RAM.

Would you be able to save RAM or flash by using uncompressed points?



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

More information about the Gnupg-devel mailing list