Re: Cryptography of GNU Name System

[Schanzenbach, Martin]

First of all: thanks for all the input. Happy for any constructive feedback.
The way I see it especially from what Jeff said is that (at least for the spec)
it is very important that it is more agile with respect to the crypto.
Just like grothoff said.
If there is no formal or informal consensus outside of GNUnet on how to do
this, then IMO we are free to go either way until there is a canonical/standard
approach to this.

However, we should prepare for such an event with respect to the protocol
design (=crypto agility).
This requires a few (significant) changes to the current spec and would
require big changes to GNUnet. An "agile" support for identity and zone
keys would affect the identity, namestore, revocation and gns components
including their storages (database layouts etc).
In other words: not happening before at least 0.14.

For now, I will try to update the spec and move it towards a more agile
crypto for zones. However, this will likely not land in GNUnet for now
as I think that is will require a lot of discussions.

BR
Martin

> On 19. Jul 2020, at 19:10, Bernd Fix <brf@hoi-polloi.org> wrote:
> 
> On 7/19/20 4:19 PM, Jeff Burdges wrote:
>> 
>> 
>>> 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.
> 
> 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.

signature.asc
Description: Message signed with OpenPGP