[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
- Cryptography of GNU Name System, Soatok Dreamseeker, 2020/07/14
- Re: Cryptography of GNU Name System, Giovanni Biscuolo, 2020/07/14
- Re: Cryptography of GNU Name System, Nikita Gillmann, 2020/07/14
- Re: Cryptography of GNU Name System, Christian Grothoff, 2020/07/14
- Re: Cryptography of GNU Name System, Jeff Burdges, 2020/07/14
- Re: Cryptography of GNU Name System, Jeff Burdges, 2020/07/18
- Re: Cryptography of GNU Name System, Bernd Fix, 2020/07/19
- Re: Cryptography of GNU Name System, Jeff Burdges, 2020/07/19
- Re: Cryptography of GNU Name System, Bernd Fix, 2020/07/19
- Re: Cryptography of GNU Name System, Schanzenbach, Martin, 2020/07/19
- Re: Cryptography of GNU Name System,
Jeff Burdges <=