Re: Cryptography of GNU Name System

[Jeff Burdges]

I just noticed you updated your comment by saying that BIP32-Ed25519 "needs 
needs a carefully designed implementation” in respond to 
https://forum.web3.foundation/t/key-recovery-attack-on-bip32-ed25519/44

I strongly disagree with the assertion that merely fixing the BIP32-Ed25519 
implementation suffices because it’s underlying design criteria is 
fundamentally flawed:  All software comes in layers and developers assume 
correct or not that tweaking one layer does not disrupt the layer below.  If 
you provide a layer that operates above a vanilla Ed25519 library like 
BIP32-Ed25519 then some developers will tweak your layer, perhaps only by 
massaging its metadata.  We then land in the situation of 
https://forum.web3.foundation/t/key-recovery-attack-on-bip32-ed25519/44 and 
your layer plus their tweaks becomes insecure.  

You can only do HDKD really safely, aka in miss-use resistant fashion, by 
shipping your own Ed25519 library that avoids clamping and ensuring your 
protocol quickly breaks Ed25519 libraries that clamp.  Yes, it's one less layer 
if you ship an unclamped Ed25519 library inside an HDKD solution, but the 
result takes far more abuse from the layer above.  


You also assert "the GNU Name System developers didn’t need to roll their own 
design, they could have used one that’s already seen real-world deployment 
instead. Why take on unnecessary risk?”  

It’s false BIP32-Ed25519 has seen real-world deployment.  I know because I 
checked before publishing that blog in 2018.  It appears BIP32-Ed25519 was only 
proposed for coins that never saw a full launch, and I never found any wallet 
makers who adopted it.  I published that blog in the hopes that no wallet maker 
would ever deploy BIP32-Ed25519.  

Also, both GNS and Tor’s solution predate BIP32-Ed25519 by like 4 years, 
although both existed earlier.  It’s actually BIP32-Ed25519 that rolled their 
own flawed design when Tor had properly researched and published an 
alternative:  
https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n2135


I do think GNS should ideally switch to Tor’s HDKD solution using Ed25519 
instead of doing ECDSA over Ed25519 of course.  And replace libgcrypt with 
boringssl wlesehwre.  At least theoretically though, ECDSA over Ed25519 should 
be far more secure than ECDSA over secp256k1 because the Edwards curve provides 
more confidence in the x coordinate mapping being as secure as a hash function. 
 ZCash researched selected Jubjub for their Pedersen hash for this reasons.

In short, I want it to be crystal clear that BIP32-Ed25519 represents a flawed 
design that fails to encapsulate it’s primitives correctly and that should 
never be shipped by anyone.  

Jeff