Suggesting Monumental Changes to Enhance the Security of Wallet.dat Files on Bitcoin

Wallet.dat Nov 11, 2020

Hey all, if you're new to what I'm talking about or what's going on, start here with this Twitter thread:

I may not know what the hell is going on in terms of the $1 billion in Bitcoin that were allegedly moved from a former Gox wallet (again, I'm not even sure if that's true, I have not looked into the specific wallet).

However, what I did do is:

  1. Take a close look at the Vice article that identified some wallet with a value of >$690M that apparently had its wallet.dat file circulating around on various darkweb exchange markets (and forums etc.)
  2. I examined the standardized encryption standards for wallet.dat files for Bitcoin (there is significant room for improvement ; the fact that the key to encrypt / decrypt the decryptoin key itself is only protected by a hash [SHA512 at that] and not a KDF'd hash function, means that its entirely possible for a dictionary attack to be leveraged against these wallet.dat files (because the passwords that are chosen are user-generated, not random , which is what you would get from a KDF function being used to generate the key). This also means that length extension attacks may be a viable
  3. Specifically, the wallet.dat file uses AES in 'CBC' mode, which I also think is a bad idea, because, with a known IV (initialization vector) and ciphertext (which is also stored directly on the device that holds the wallet.dat file), one could actually alter the underlying text of the wallet.dat file (https://crypto.stackexchange.com/questions/85785/can-you-change-an-aes-encrypted-message-if-you-control-the-iv; this link actually provides a step-by-step guide on how to do this via Python / Shell [you can even choose your preference - we'll upload the finished script for anyone feeling adventurous today] https://crypto.stackexchange.com/questions/85785/can-you-change-an-aes-encrypted-message-if-you-control-the-ive time)
  4. Confused about the implementation of a raw, untransformed hash as the derivation for the password here (with SHA512), feels like this renders this vulnerable to potential length extension attacks (more information on that found here = https://blog.skullsecurity.org/2012/everything-you-need-to-know-about-hash-length-extension-attacks
  5. Specifically, the wallet.dat specification for Bitcoin (per the Bitcoin Wiki), states: "*Wallet encryption uses AES-256-CBC to encrypt only the private keys that are held in a wallet"; this is fine thus far. But then it claims that the keys are encrypted with a "master key which is entirely random" --- that encryption being AES-256-CBC (which needs an encryption / decryption key). Things fall apart though when it states that the encryption / decryption for the AES-256-CBC encrypted keys are, "Derived from the passphrase using SHA-512" (clearly no KDF mentioned here; thought it was possible that this was an error in the documentation itself but...no; it isn't).

Choosing the AES Mode to Replace the Current One Used For Wallet.Dat Encryption on Bitcoin

Ideally, we're going to want one that provides us:

  1. Resistance against replay attacks (meaning it needs to be iterated with crypto primitives that involve the use of a nonce of some sort [hence those stream encryption concepts like chacha20 where there is an accompanying & increasing hash])
  2. Authenticated Data
  3. AES (key-wrapping mode) & also AES-512-SIV (per the specifications given by the IETF)
  4. There isn't an explicit KDF that's used, but there is a call via OpenSSL api which provides a salt alongside SHA256 + tens of thousands of iterations too. yption being AES-256-CBC (which needs an encryption / decryption key). Things fall apart though when it states that the encryption / decryption for the AES-256-CBC encrypted keys are, "Derived from the passphrase using SHA-512" (clearly no KDF mentioned here; thought it was possible that this was an error in the documentation itself but...no; it isn't).

Recommendations

  1. Swap out the current encryption mode for AES with AES-512-SIV. This will actually allow for the handling of 512-bit keys.
  2. Trash 'SHA512'entirely here in this situation.
  3. The reason why 'SHA512' should be trashed is because of the KMAC function that will be used in conjunction with AES now (that's going to make up for the AES that we would have otherwise been using)
  4. XChaCha20-poly1305 will be deployed for any and all things that need to be transmitted (i.e., a Bitcoin transaction).
  5. Maybe Bitcoin should consider whether they want to support the use (or the optional feature of "authenticating" with a set of nodes that one knows to be the correct identities on the protocol ; perhaps could be in the form of users performing their own authentication for data that they choose to accept themselves.)

Tags

cryptomedication

Happy to serve and help wherever I'm needed in the blockchain space. #Education #EthicalContent #BringingLibretotheForefront

Great! You've successfully subscribed.
Great! Next, complete checkout for full access.
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.