w3f
Additive vs multiplicative
We should clean this crate up so we can finalize everything.. as changing a deployed HDKD scheme really sucks.
Issues worth considering:
Should we seek compatiblity with existing hard-only derivation schemes used by Trezor, etc.?
Should we do soft additively like done here currently and done in BIP32? Or multiplicatively like Tor does?
We've no reason to seek any compatiblity with Tor's scheme, but we could just for the hell of it. Thoughts?
ref. https://github.com/paritytech/substrate/issues/3294
cc @bddap @jacogr @kianenigma
Not the expert here...
The beauty of the current (very simplistic, hard-only) ed25519 derivation in substrate -
- it brings in no dependencies on external crates, i.e. to implement you don't need additional libs in non-Rust environments (e.g. WASM, C++, etc.)
- assuming you have an ed25519 implementation, it is easy to do (e.g. hardware wallets with limited resources can adapt it easily)
The first category above can easily adapt, the second category may be easier to do with a known and existing standards, if we were to change it. If all things are equal, probably need to look at what can be done with little effort in all wallet environments, especially in the cases where there are high security, but limited resources.
As an aside, yes, "changing a deployed HDKD scheme really sucks" ;)
Id the existing hard only derivation compatible with anything else like Trezor or whatever?
Page 4 of https://eprint.iacr.org/2021/273.pdf shows an advantage for multiplicative blinding in an OPRF used in some PAKEs. It's not at all the same situation, but..
It's worth considering if additive blinding interacts poorly with any protocols, like maybe Claus blind signatures. A priori, I doubt Claus blind signatures could even be combined securely with any soft key derivation scheme since the user could always deform keys. It's possible the client commits to the derived key in round one though, when using a multiplicative blinding, except really any deployment should hash the public key, which makes this similar.
I doubt multi-signatures exhibit problems since the signers compute the hashes themselves.
We should switch to multiplicative derivation since that's what Tor and GNUNet's GNS both do. If I recall, we cannot match Tor's approach but we can converge with GNUNet's version.