You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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).
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.
The text was updated successfully, but these errors were encountered: