HDKD

[burdges]

IEEE published a flawed HDKD design called BIP32-Ed25519. I explained a secret key recovery attack based on this flaw in https://forum.web3.foundation/t/key-recovery-attack-on-bip32-ed25519/44 but that zombie lives.

In the interest of killing bad crypto, I'd love it if ed25519-dalek implemented Tor's "soft derivation" scheme from https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n2135

One could discuss additive vs multiplicative blinding ala w3f/hd-ed25519#3 too, but maybe Tor compatibility wins there. We could do this in https://github.com/w3f/hd-ed25519 but that code kinda sucks and maybe should die, maybe best to some nicer looking thing vaguely like https://github.com/w3f/schnorrkel/blob/master/src/derive.rs here.

In principle, one might implement some "hard derivation" scheme already used by some hardware wallet maker alongside this too, which actually sounds harder since someone must track down the popular ones. I hear Ledger has something they call SLIP-0010.

[kirushik]

For future reference, this is the spec for SLIP-0010, which is indeed used in Ledger (and, consequently, in current implementations of relevant cryptowallets, like ledger-kusama).