Topic: Wallet.dat filename obfuscation, anti-recovery techniques (Read 1222 times)

Uh.... I just encrypt my whole drive.

(this response is a little OT from OP's thoughts, but regardless) That pretty much works, except that you have to mark the one address that's created before the password is added as unsafe, because it's already been saved unencrypted to the hard drive. It's also not very user-friendly, compared to creating a wallet that's encrypted before ever being saved.

Lot harder for whom? For ourselves?
Let us use the simplest way: every time you are not sure that your private keys are safe...
1) create new passworded wallet.dat
2) check several times that you can lock and unlock it
3) backup it several times (as usually)
4) and transfer all your funds to new address.

Voila! Let hackers investigate your old hard drive! They will find nothing on it
(ok, you can also import old private keys to new wallet.dat)

As you noted it's all just obfuscation, and so I assume you know how much better encryption is at privacy protection over obfuscation.

So what is it you're really trying to accomplish? Given an answer to this, the better solution is to apply encryption to what you're trying to accomplish instead of obfuscation, isn't it?

For example, are you trying to improve privacy (to make it more difficult for malware to read pubkeys, txs, and the like)? Then (as you already noted in your follow-up post) a better solution would be to add a second password, let's call it the "watching-only" password, which encrypts the entire wallet. The "privkey" password would continue to work as-is. The watching-only password would need to remain in memory, so it wouldn't protect against malware that has acquired root, but it would help otherwise.


This I like, given that it will prevent plaintext privkeys from ever seeing a hard drive platter. Some wallets already implement this, and it'd be nice to see Bitcoin Core do so as well.

Well, it strikes me as odd that we even allow a password-protected bitcoin wallet to be accessed without a password. The whole file could be encrypted. There is a lot of information to be taken from a wallet that users may want to protect from adversaries that may gain local access.

I just read quickly, but the following point stood out and would break your whole proposal IMHO:


So I have to keep my password/-phrase in memory even when I just want to read my balance? This sounds very bad to me. This would require me to enter my password every time I start the wallet.

I will preface this post by saying that I haven't really sussed out what would be a practical inclusion in Bitcoin, I'm just brainstorming here.

I was using my philosophy time to think about the dangers of old hard drives and recoverable wallet files and key data left behind on them, even if files are deleted. Tools such as pywallet can scan an entire hard drive surface for Bitcoin private keys, recovering them from deleted files and removed partitions. Can we make this a lot harder?

Tools to erase hard drive free space generally do this on live volumes by creating one huge file taking up the remaining disk space, filled with 0s or pseudorandomness, and then delete the file. My first thought was that such a tool could instead fill a hard drive's free space with entries that would look like recoverable keys to known utilities, making gigabytes of data be recovered by such tools.

This only takes a smarter utility to defeat. Wallet.dat files have a specific format, and if recovery isn't so much desperation as it is opportunistic (such as checking 100s of recycled drives or scanning the disks of 1000s of PwNd computers), we can just target the low-hanging fruit where an intact wallet appears in the free space or was never deleted at all. Of course the biggest problem is that even the stupidest trojan horses know the default wallet location to steal.

So we need to fill the hard drive space with real-looking wallets. Not just real-looking, let's call it undetectably the same as a real wallet. Real wallets have more than 100 addresses, have labels created by the user, have a best-block hash, have a separate list of address names, have a future-pool with timestamps, and have real transactions with scriptsigs, txids, and various amounts. The creation date and last use date can be gathered, and more advanced tools may be able to quickly discard fake wallet data by tx, signatures, or pubkeys not actually in the blockchain.

How then can we make a whole bunch of real-looking wallet data indistinguishable from real wallets? The obvious way is with Bitcoin itself. Bitcoin is already a data hog, why not let it have a few more gigs if desired for more security.

Imagine if Bitcoin did this:

• Security-enhanced Bitcoin asks for your encryption password before it even makes a wallet.
• Instead of wallet.dat, the filename is wallet.(SHA256^bcrypt of passphrase).dat - you need the password to know the correct wallet file name.
• Bitcoin makes thousands of fake wallets at the same time, with the real wallet created randomly during this,
• All those other wallets are named and encrypted with a PRNG from the passphrase so we can talk to them also,
• Every time the wallet is touched, the fake wallets are also updated,
• You make a transaction, the fake wallets also get fake (real) transactions taken from the blockchain,
• You get a payment, more fake data from the blockchain (or we just watch the swiped addresses for payments)
• We can use a mix of either putting real wallet labels in fake wallets or garbage labels in fake wallets

About the only limitation in stuff we can fake is that in real wallets, the keypool becomes real addresses. Since wallets don't have a history of how things were, we can simulate this by deleting the keypool pubkey and replacing it with a blockchain-seen one.

So we've not exactly wiped the hard drive space or filled the drive with junk, but we've made identification of the real wallet much harder and given an internet cracker a GB or more to steal off a compromised computer before he can go to work. We still can use idle time to create free-space wiping temp files with more wallet-like data if the user wants.

This is not hard security, only obfuscation, and would require careful thought to not taint fake wallets with identifying factors.

Thanks for reading and your responses.