Re: Cryptography of GNU Name System

[Jeff Burdges]

> On 19 Jul 2020, at 14:08, Bernd Fix <brf@hoi-polloi.org> 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