bitshares1-core icon indicating copy to clipboard operation
bitshares1-core copied to clipboard

Serialize encrypted private keys with checksums

Open testzcrypto opened this issue 10 years ago • 4 comments
trafficstars

DevShares 0.5.0 steps to reproduce: Enter wallet_import_keys_from_json with wrong passphrase

testzcrypto avatar Jan 08 '15 21:01 testzcrypto

At the moment there is actually no way to check if decryption failed because of a bad password or because the data isn't actually an encrypted private key. To do this we need to serialize private keys with a checksum and also serialize the encrypted version with a checksum.

I am removing the milestone until we get that implemented.

I added a warning that the password might be wrong as a ulog, we should make another warning separately in the GUI.

nmushegian avatar Jan 09 '15 21:01 nmushegian

This is interesting because I was not aware that there are unencrypted private keys in the wallet.json. I usually check the password against the master_key_record_type checksum and if that passes then I am able to decrypt and use all of the "encrypted_private_key" entries. I must be missing something in the scope of this feature.

jcalfee avatar Jan 09 '15 21:01 jcalfee

This feature is supposed to import any private key form from arbitrary JSON, for example from my bitcoin privkey dumps. Now that I think about it, I'm assuming the keys are encrypted using our scheme. The correct thing is to add more decryption schemes. This isn't the "wallet_backup_restore" feature.

nmushegian avatar Jan 09 '15 21:01 nmushegian

What you want is an unencrypted magic number appended to the encrypted key to say "THIS IS A PRIVATE KEY" (as opposed to some other arbitrary data). Like the letters "MZ" [1] at the beginning of every Windows exe file, or 0xCAFEBABE for Java class files.

Then we have a checksum appended (or prependend) to the key and encrypted along with it.

So if a file contains a base64 string with the right (unencrypted) magic number, but when decrypted has a checksum mismatch, we can say with confidence that we have a private key that was improperly decrypted -- and tell the user they entered an incorrect password.

We will also be able to detect json files that don't use this scheme -- none of their strings will have the magic number (provided the magic number is enough bytes that it's unlikely to appear by chance).

[1] http://en.wikipedia.org/wiki/Mark_Zbikowski

theoreticalbts avatar Jan 10 '15 00:01 theoreticalbts