Re: [GNUnet-developers] EcDSA signature scheme

[Jeff Burdges]

> On 13 Jul 2018, at 18:39, Bernd Fix <address@hidden> wrote:
> My point was that EdDSA (and the flag "eddsa" used with gcrypt) refers
> to and enforces the Ed25519 curve. For implementations not using gcrypt
> that can be a problem as ECDHE requires operations on the curve (scalar
> multiplication of a arbitrary point) that a lot of libraries do not
> support. But I understand why that is not an issue for GNUnet itself.

If you need this but do not trust libgcrypt, like say for an embedded platform 
or javascript, then you can use the rust library curve25519-dalek and write 
bindings for C or whatever.  It’s tricky compile rust code down to a minimal 
footprint binary, but easier than doing the same for libgcrypt.

> As you said: X25519 is based on Curve25519, not Ed25519 (although there
> is a bijective mapping between them).

They are different equations representing the same curve, but there is no 
bijection between public keys because X25519 lacks the sign bit.  A Taler 
wallet cannot refresh compatibly without doing the DH on the Edwards curve.  A 
Taler exchange cannot compatibly validate refreshes without doing the DH on the 
Edwards curve.  If an exchange approves both points then they create a refresh 
loophole.

Jeff

signature.asc
Description: Message signed with OpenPGP