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:
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.)
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
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)
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
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).
- Swap out the current encryption mode for AES with AES-512-SIV. This will actually allow for the handling of 512-bit keys.
- Trash 'SHA512'entirely here in this situation.
- 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)
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:
- 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])
- Authenticated Data
- AES (key-wrapping mode) & also AES-512-SIV (per the specifications given by the IETF)
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. 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).
OpenSSL Will Screw You
Unfortunately, in this case (as with many others), OpenSSL handles the API syscall for the salting of the input in an idiomatic fashion for which there is no rhyme or reason for (this has been observed by multiple different users across the internet and it appears that there is no rationale for OpenSSL's break from straightforward arithmetic processing for the cryptographic functions involved in transforming the piped input to a salt):
- As it stands, there is no guarantee that users will be able to decrypt their wallet.dat files in the future if they attempt to acecss it on another machine (even if all of the inputted information is 100% correct); this is due to the enigmatic processing of the OpenSSL library that's called as part of the encryption function. Since there is no rhyme or reason for this aberration, we cannot even be certain that OpenSSL's behavior here will be consistent across updated versions (or on different CPU architectures). This is why libraries like 'Valgrind' can be useful in mitigating issues like this (to a certain extent)
- The overall hash function is just not that secure; juxtaposed with the increasing prevalence of powerful GPU processors in consumer computers (by way of NVIDIA / AMD releases and 'gamer' culture that ensures that these GPUs fly off the shelves the minute that they're released) plus the tendency of end users to choose less than secure passwords in general (especially if they believe there's a KDF / cryptographic scheme there to compensate for their password's weakness), we have a clear recipe for disaster.
- Bitcoin addresses are generated deterministically (unlike the current standardized process for generating keys by the OpenPGP standard, by contrast). This combined with the fact that Bitcoin is a stateless protocol allows for users to generate their wallet addresses in accordance with BIP38 (Keybase's altered version), which allows users to generate a Bitcoin wallet address without needing to store the password anywhere on planet earth (i.e., via the 'brainwallet' technique). The Keybase implementation is exponentially more secure than the 'mnemonic phrase' seed generation method we see propagated by nearly ever single wallet service provider in blockchain currently (in accordance with BIP39, which was never accepted as 'standardized practice' by the Bitcoin Core developer team (making its widespread use pretty erroneous).