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
