[BC/CWC] Wallet private key updates [1]#4068
[BC/CWC] Wallet private key updates [1]#4068MichaelAJay wants to merge 29 commits intobitpay:masterfrom
Conversation
…sses, & expose method with DeriverProxy
…sses and add passthrough on DeriverProxy
…t to expected form
kajoseph
left a comment
There was a problem hiding this comment.
I think a better approach may be to auto migrate wallets with version < 2 to v2. That way we can avoid carve-outs while actively push better security.
loadWallet() {
const wallet = read wallet file;
if (wallet.version < 2) {
convert to v2 wallet;
backup wallet file to .bak;
overwrite wallet file with v2;
}
}
…loadWallet with 'raw' param
…t-privatekey-ref
…t-privatekey-ref
| } | ||
| } | ||
|
|
||
| export function encryptPrivateKey(privKey, pubKey, encryptionKey) { |
There was a problem hiding this comment.
Should we mark as @deprecated and use encryptBuffer instead? We could also just make this a wrapper for encryptBuffer...
| describe('signTx v2 key handling', function() { | ||
| let txStub: sinon.SinonStub; | ||
| afterEach(async function() { | ||
| txStub?.restore(); |
|
|
||
| /** | ||
| * New methods | ||
| * TODO: Deprecate above as necessary |
There was a problem hiding this comment.
Should we mark the above as @deprecated?
| const pubKey = CWC.Deriver.getPublicKey('ETH', wallet.network, privBufForPubKey); | ||
| privBufForPubKey.fill(0); | ||
| const privBuf = CWC.Deriver.privateKeyToBuffer('ETH', privHex); | ||
| // v2 key encryption uses the key's pubKey as the IV salt (not the wallet pubKey) |
There was a problem hiding this comment.
?? As far as I can tell, they both set the IV the same way.
| return this.get(chain).privateKeyToBuffer(privateKey); | ||
| } | ||
|
|
||
| privateKeyBufferToNativePrivateKey(chain: string, network: string, buf: Buffer): any { |
There was a problem hiding this comment.
Avoid any. Every fn returns a string - might as well type it.
| /** | ||
| * Temporary - converts decrypted private key buffer to chain-native private key format | ||
| */ | ||
| privateKeyBufferToNativePrivateKey(buf: Buffer, network: string): any; |
There was a problem hiding this comment.
Sort of. It depends on how much we want THIS PR to do.
The point of this is that it pushes the buffer private keys all the way to the boundary - Wallet side.
Next would be updating the called libraries and sending buffers straight on through.
I think that should be a second effort after this one.
bitcore-client
Encryption
Storage
addKeysSafe- incoming keys' private key is encrypted, so not immediately available to be used to retrieve pubkey, which should be available anyway. Throws if missing a pubkeyWallet
createencrypts HDPrivateKey xprivkey and privateKey so they can be decrypted as buffers instead of serializing the whole masterKey and THEN encryptingimportKeysdoes the same for signing keyssignTxdecrypts to buffers then uses deriver for chain-aware decoding. In the next phase, this decoding should be made unnecessary by passing the buffer all the way through to use, if possibleTests
crypto-wallet-core
Derivation
privateKeyToBufferandprivateKeyBufferToNativePrivateKeyto IDeriver & implement for each Deriver - no need to override for any of the extending classes (UTXOs to AbstractBitcoreLibDeriver & EVM to EthDeriver)