> On 19 Jul 2020, at 14:08, Bernd Fix <[email protected]> wrote:
> Compared to the current GNS implementation this all boils down to
> replacing ECDSA with a non-standard EdDSA - is it worth the trouble?
It depends on how niche ECDSA on Ed25519 is. It’s clearly more work to ship an
Ed25519 if your library provides the non-stnadard combination of ECDSA on
Ed25519. If we assume that libgcrypt must be scrapped eventually, then it’s
maybe less work to ship an tweaked Ed25519 than to supporting that
configuration on another cryptographic library. It depends what other
libraries support of course, but increasingly they’re removing such
flexibility, while implementations continue becoming more flexible.
There is one argument for making Tor’s solution part of semi-standard libraries
implementing Ed25519, which goes: If abused in foreseeable ways, then
BIP32-Ed25519 becomes, but cryptocurrency applications are going to do HDKD
regardless, so their security is improved if Tor’s solution is adopted by
Ed25519 libraries.
Are there any arguments for supporting ECDSA on Ed25519 that do not mention
GNUNet? I suppose doing both HDKD and ecRecover on Ed25519, presumably again
in cryptocurrency applications, but that’s kinda ridiculous since ecRecover
trashes batch verification.
Jeff
