> On 13 Jul 2018, at 18:39, Bernd Fix <[email protected]> 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
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
