gnunet-developers
[Top][All Lists]
Advanced

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

Re: Cryptography of GNU Name System


From: Jeff Burdges
Subject: Re: Cryptography of GNU Name System
Date: Sun, 19 Jul 2020 21:50:05 +0200


> On 19 Jul 2020, at 19:10, Bernd Fix <brf@hoi-polloi.org> wrote:
>> 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... ;)

Isis Lovecruft exposed a ExpandedSecretkey type that makes doing this possible: 
 https://github.com/w3f/hd-ed25519/  It changes nothing about how r gets 
derived.  As I said before, I should presumably switch that crate to doing 
Tor’s solution: https://github.com/w3f/hd-ed25519/issues/3

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

We do not need to switch right now, but increasingly Schnorr (Ed25519) is 
preferred over ECDSA. 

There is afaik only one advantage of ECDSA over Schnorr:  In Schnorr, you 
cannot do the smaller signatures that output the public key, aka ecRecover, 
becuase they require not hashing the public key into the challenge, which makes 
HDKD insecure.  

We’ve no idea if this is really secure with ECDSA, especially hen combined with 
other complex protocols on ECDSA, but people do this anyways.  We do know not 
hashing the public key break batch verification.  We also know Schnorr gives 
many other cool things like fairly simple multisigs, blind sigs, adaptor sigs, 
etc.

Jeff





reply via email to

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