Re: Cryptography of GNU Name System

[Jeff Burdges]

> On 14 Jul 2020, at 06:02, Soatok Dreamseeker <soatok.dhole@gmail.com> wrote:
> Please read: 
> https://soatok.blog/2020/07/08/gnu-a-heuristic-for-bad-cryptography

There are definitely issues with using ECDSA when a bespoke Schnorr variant 
works better, but..

BIP32-Ed25519 was incompetently designed.  I broke it pretty trivially: 
  https://forum.web3.foundation/t/key-recovery-attack-on-bip32-ed25519/44/3

As I describe, there are two “real” fixes, either use the Tor solution 
  
https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n2135
It kinda highlights the incompetence in bip32-ed25519 that Tor’s correct 
solution predates theirs incorrect one by like 5 years.

I actually did a quick correct implementation that more closely resembles BIP32 
than Tor’s solution in  https://github.com/w3f/hd-ed25519/  but there is no 
reason to have two solutions running around, so if you want to use it then I’d 
advise just switch it to agree with Tor’s method, and send me a PR.  

There are two reasons for GNS using ECDSA over Tor’s solution, GNS predates (1) 
Tor’s new onion services by years, and (2) GNS wants off the shelf Ed25519 
implementations, which any correct solution breaks, not sure that (2) remains 
relevant today.


As an aside, I avoid doing too much work that encourages HDKD because it 
creates strange vulnerabilities elsewhere in protocol stacks.  It’s likely GNS 
avoids this, but replacing ECDSA with Schnorr reduces concerns.  I think 
Bitcoin and Ethereum take much bigger risks, due to using ecrecover and complex 
multi-signatures for ECDSA, and using adaptor signatures for payment channels. 


There are wider issues with GNS but the are of the form:  Can you make GNS user 
friendly?  We’ll never seen an attempt to make GNS user friendly so nobody 
really knows until they try and fail, but it’s still kinda the fundamental 
question.


I think GNUNet and GNS symmetric cyphersuit selection occurred well over a 
decade ago, so sure they should be updated eventually, but whatever.  We’ve 
seen numerous problems in all TLS implementations, and the TLS standards 
themselves, so not sure at what points in time a casual observer might think 
GnuTLS seemed better or worse.  We’d all agree that GnuTLS and libgcrypt really 
suck today of course.  An OpenSSL/LibreSSL suggestion worries me however.  
Imho, one should be using Google’s BoringSSL or a derivative like the rust ring 
crate because way more money gets spent fixing BoringSSL than fixing GnuTLS. 

Jeff

p.s.  There is an issue with "free software" projects not being best in class 
for security, and GnuTLS and libgcrypto may make good examples, but research 
projects like GNUNet do not make good examples.  There is one truly shining 
example of free software ideology not aligning with security however:  Debian’s 
default XMPP client is empathy.  Yet, empathy’s developers are openly hostile 
to end-to-end encryption like the off-the-record messaging protocol because 
encryption conflicts with their application structure.  It’s obvious empathy 
should’ve been removed from Debian stable over 5 years ago, but it lives on..