[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cryptography of GNU Name System

From: Bernd Fix
Subject: Re: Cryptography of GNU Name System
Date: Sun, 19 Jul 2020 17:10:15 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

On 7/19/20 4:19 PM, Jeff Burdges wrote:
>> On 19 Jul 2020, at 14:08, Bernd Fix <> 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.

True indeed. Actually in languages like Go there is no "flexible"
Ed25519 implementation; they only implement it as far as EdDSA is
concerned. Which means that neither ECDSA over Ed25519 nor the signature
scheme proposed by Tor can be done with them natively. This is why I
went through all the troubles to implement Ed25519 in a generic way so
it can be used for things like that...

> 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.

Actually implementing Tor's proposal can be done in my Go implementation
in less than 5min (if we agree on something standard for chossing 'r'
deterministically), but what would the new signature scheme be called?
EdDSA is out of question... ;)

> 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.

Who bears the burden of proof? Those who propose ECDSA over Ed25519 or
those who propose Tor's key derivation signature scheme? Is there *any*
objective reason why one is more secure than the other? If there is such
a good argument, I would be the first to switch schemes.

Cheers, Bernd.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]