Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Store XORed wallet seed in-mem #200
Experimental, trying to figure out the most desirable way to store an XORed wallet seed and pass around the token to reconstruct it. My first inclination is to just ensure all calls to wallet.keychain() take an optional token so as ensure it's impossible to miss it anywhere in the code (as opposed to requiring an explicit call to an
Edit: ready for merging, these are the features here.
It appears a lot of things have changed here, but the majority are just propagating the mask throughout and test updates. I'll go through and point out the interesting bits.
Token and keychain_mask are the same, still working on naming.
Optional because a) I want to keep it as an option on the trait, rather than force other keychain implementations into using this and b) it still needs to be optional for backwards compatibility reasons with older functions, and right now it feels like it will be less hacky to have the XOR feature optional on the keychain rather than providing fake in-process tokens for the foreign API and/or directly linked wallets. Will see how it turns out and the Option can always be dropped in later versions.
chisa0a left a comment
LGTM. As long as the XOR key is only used against one plaintext (the master seed), no issues. Looks like a new mask is generated for a new seed right? E.g. a wallet with a stored mask that generates a new seed won't use the same mask against the new seed?