Store XORed wallet seed in-mem #200
Conversation
|
I like the idea of not requiring pre-/post-conditions (open/close) on the wallet. Why optional though? It would always be required. |
|
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. |
yeastplume
changed the title
|
Should be ready for reviewing, I've updated the top comment and will point out a few things in the code |
| @@ -67,6 +68,8 @@ where | |||
| pub doctest_mode: bool, | |||
| /// foreign check middleware | |||
| middleware: Option<ForeignCheckMiddleware>, | |||
| /// Stored keychain mask (in case the stored wallet seed is tokenized) | |||
| keychain_mask: Option<SecretKey>, | |||
There was a problem hiding this comment.
This is now just stored by a Foreign API instance, for the case where you want to run a foreign and owner API in the same process but only reference a single instance of the wallet.
| @@ -99,6 +103,8 @@ where | |||
| data_file_dir: String, | |||
| /// Keychain | |||
| pub keychain: Option<K>, | |||
| /// Check value for XORed keychain seed | |||
| pub master_checksum: Box<Option<Blake2bResult>>, | |||
There was a problem hiding this comment.
This is here because an incorrectly masked key is indistinguishable from the right key. The idea here is to keep a hash of the seed so we can verify whether the stored_seed^mask is correct and return an appropriate error if so. Otherwise it'll just look to the user like their outputs have disappeared when they provide the wrong mask.
| @@ -131,7 +132,13 @@ where | |||
| Ok(()) | |||
| } | |||
|
|
|||
| fn open_wallet(&mut self, _name: Option<&str>, password: ZeroingString) -> Result<(), Error> { | |||
| fn open_wallet( | |||
There was a problem hiding this comment.
Modified to return the mask if create_mask is true.
|
@chisa0a Thanks for the review, yes the XOR key is ephemeral, not stored anywhere and re-generated whenever open-wallet is called. |
* experimental xor token work * rustfmt * test implementation of build_coinbase_t function * rustfmt * add separate foreign_rpc_s interface for secure functions * rustfmt * rustfmt * fix http scheme to allow https as well * add tokenized owner API, modify all functions to use token * rustfmt * fix for api doctests, tests passing up to api crate * rustfmt * controller crate compilation * rustfmt * controller tests passing and modified some to use masked keychains * rustfmt * fix wallet tests * rustfmt * build from github * rustfmt
* experimental xor token work * rustfmt * test implementation of build_coinbase_t function * rustfmt * add separate foreign_rpc_s interface for secure functions * rustfmt * rustfmt * fix http scheme to allow https as well * add tokenized owner API, modify all functions to use token * rustfmt * fix for api doctests, tests passing up to api crate * rustfmt * controller crate compilation * rustfmt * controller tests passing and modified some to use masked keychains * rustfmt * fix wallet tests * rustfmt * build from github * rustfmt
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
open(token)close(token)type function anywhere the wallet is called.Edit: ready for merging, these are the features here.
Option<SecretKey>representing the mask to be passed along everywhere the keychain is needed. I think this is better than inserting open/close statements in the code (a bit more prone to bugs in future development).open_walletthat determines whether the key gets masked. If this is false, it returns None and all wallet API calls can be made with None as the mask. If true, it returns the mask that needs to be provided.start_secure_apiis called (will save details of that for the next PR.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.