GnuPG versus TrueCrypt

[BombaUcigasa]

When decrypting my wallet it gets stored unencrypted in my hard drive right? Sure, I can shred and delete it after re-encrypting but that's a security risk TrueCrypt doesn't have.

Btw, I didn't read the whole Schneier paper but the abstract only talks about losing deniability under Windows with TrueCrypt version 5. Should I still be concerned about this using TrueCrypt v7 under Linux?

What about in-memory attacks? Using truecrypt, you will have parts of the file in-memory, and even in-swap, such that it could get on the hard-drive. Not to mention someone can sniff your Truecrypt password either keylogging it or in-memory. Even using a VM would do nothing to increase security, you must absolutely make sure you have no malware running on any outer OS layer from which you access your wallet from.

[gene]

When decrypting my wallet it gets stored unencrypted in my hard drive right? Sure, I can shred and delete it after re-encrypting but that's a security risk TrueCrypt doesn't have.

Btw, I didn't read the whole Schneier paper but the abstract only talks about losing deniability under Windows with TrueCrypt version 5. Should I still be concerned about this using TrueCrypt v7 under Linux?

Good point about the secure deletion, but the solution to run an srm (or rm -P) on the file just seems easier to me than to install a whole other crypto framework.

Not sure what the state of the newer versions is. Keep in mind that the issue was with the deniable filesystems.

[kwukduck]

I thought of securing my wallet for a while and came up with the following


- Think of a strong password you can memorize. We call it PassA
- Generate a long random password. I call it PassB
- Create a small truecrypt container that holds the wallet(s) i want to backup/store. The password used on this volume would be made up of both PassA+PassB or PassB+PassA or just pick a place where to insert PassA into the string of PassB (do remember that position though!)

Now split up PassB using Shamir's sharing scheme. Hold a few shares yourself so you don't need many to recover PassB
Give some shares to your friends, family, colleagues, etc.

I thought of using gpg for the wallet but the issue of having the wallet file on disk temporary bugged me, recovery is easy.
I can just point a portable bitcoin version to the truecrypt volume to access the wallet file.
That's the reason i picked TC over GPG. I do agree that GPG is in general the better one though.

Anyone sees a better way to do this using GPG?

[Nesetalis]

if you were going the printing out a paper route, why not just print out your wallet file and delete the original?

wallet.dat is a binary file, not something you can print out unless you intend to write it in binary.

encrypting it in to something displayable as visible characters allows you to read it back in.

[gene]

I thought of securing my wallet for a while and came up with the following


- Think of a strong password you can memorize. We call it PassA
- Generate a long random password. I call it PassB
- Create a small truecrypt container that holds the wallet(s) i want to backup/store. The password used on this volume would be made up of both PassA+PassB or PassB+PassA or just pick a place where to insert PassA into the string of PassB (do remember that position though!)

Now split up PassB using Shamir's sharing scheme. Hold a few shares yourself so you don't need many to recover PassB
Give some shares to your friends, family, colleagues, etc.

I thought of using gpg for the wallet but the issue of having the wallet file on disk temporary bugged me, recovery is easy.
I can just point a portable bitcoin version to the truecrypt volume to access the wallet file.
That's the reason i picked TC over GPG. I do agree that GPG is in general the better one though.

Anyone sees a better way to do this using GPG?

A few points.

I'm not convinced (nor are many people who know far more about these things) that recovery is easy, at least after overwriting the file using shred or a normal system utility like srm or rm -P. Also, you can have the exact same shared password scheme with any encryption tools, not just TrueCrypt. A GPG private key (which is required for full functionality) typically also requires a passphrase to unlock.

Seems to me like you are trying to avoid having a clear-text wallet.dat on the computer. Without getting too off-topic, we are talking about different goals. The use of GPG here is to encrypt data which is "at rest" -- like for backup or archival. Disk encryption (which grants access to a filesystem but makes data hard to get once the image is unmounted) tries to defend against a different threat -- someone stealing the computer. As mentioned above, these disk encryption schemes can also be defeated in various ways.

Many operating systems include mechanisms for disk encryption. This was TrueCrypt's claim to fame before bitlocker/filevault. Now, TrueCrypt's raison d'etre is the so-called "deniable" filesystem.

"Containers" are essentially disk images that you mount from within TrueCrypt. GPG-encrypted files are just... files. My point in creating this thread was to suggest that GnuPG would be a more suitable and trustworthy tool for the sorts of things use that most bitcoin users would be doing.

[bcearl]

Bruteforce cracking. 5 chars alphanumeric passwords.

There are several ways of brute force cracking. Did you call the 7z-extractor for each password? No attacker would do that!

Have you tried this?
http://sourceforge.net/projects/sevenzcracker/files/
or this?
http://sourceforge.net/projects/rarcrack/files/rarcrack-0.2/%5BUnnamed%20release%5D/

Send me an archive with 5 alphanumeric characters, I could crack it today! (Somebody who would put some effort in writing his own 7zip-tools would be much faster.)

http://content.wuala.com/contents/entropiahost/Share/bitcoinpassword.7z?dl=1

There you go. 294 bytes. Five chars alpha-lowercase and numeric password. If you successfully crack it, you can give me the password that is contained inside the textfile.

It's a total waste, but I have it running now (on my slow old laptop).

The rate of tested passwords looks like it will be finished after 4 hours on average.

[jhansen858]

Heres the best way


1) create a truecrypt container
2) encrypt your wallet with gpg
3) move encrypted wallet in truecrypt container and unmount
4) now use 7z to add that truecrypt container to an encrypted archive and email to your self

[jhansen858]

5) take that 7z file and insert the sequences into the genetic code of a monkey
6) wait for that monkey to have 3 babies, seperate them and send them to different parts of the planet
7) the completed key will be contained in the genetic sequences of the 3 monkeys.

[nathanrees19]

TrueCrypt's novel feature is the "deniable" filesystem. Bruce Schneier has published some work on it and stated that he "wouldn't trust it."

So we cannot break the deniability feature in TrueCrypt 6.0. But, honestly, I wouldn't trust it.

He doesn't seem to provide a reason to not trust it. I would take the direct statement of fact over his gut feeling.

If you want to encrypt wallet files for backups, use GPG.
If you want to protect the wallet file from being stolen from your disk, use encrypted folders of the kind that your operating system provides. But don't expect it to be protected against malware while in use. Everything you have access to, the malware you catch has access to, too. It will protect you against people who steal your computer, but it will not protect you against malware.

Truecrypt will do *both*, if you set your .bitcoin directory to inside the container. To backup you simply copy the container. The wallet never touches the drive unencrypted, and there's no need to trust your operating system to do it right (EFS in Windows is breakable).

You can even have a fake wallet with the real wallet in a hidden volume. If the directory structure is the same, no traces will be left on-disk if you use the hidden one or not.

[BombaUcigasa]

http://content.wuala.com/contents/entropiahost/Share/bitcoinpassword.7z?dl=1

There you go. 294 bytes. Five chars alpha-lowercase and numeric password. If you successfully crack it, you can give me the password that is contained inside the textfile.

It's a total waste, but I have it running now (on my slow old laptop).

The rate of tested passwords looks like it will be finished after 4 hours on average.

Really? Just 4 hours? That's some pretty good cracker you have there. Again, the one I used the last time to test things out got about 3-4 keys per second. So 4 hours at ~100W would mean it costs less than 0.1$ to crack a 5 char password? We really need to use longer literal passwords then...

[bcearl]

http://content.wuala.com/contents/entropiahost/Share/bitcoinpassword.7z?dl=1

There you go. 294 bytes. Five chars alpha-lowercase and numeric password. If you successfully crack it, you can give me the password that is contained inside the textfile.

It's a total waste, but I have it running now (on my slow old laptop).

The rate of tested passwords looks like it will be finished after 4 hours on average.

Really? Just 4 hours? That's some pretty good cracker you have there. Again, the one I used the last time to test things out got about 3-4 keys per second. So 4 hours at ~100W would mean it costs less than 0.1$ to crack a 5 char password? We really need to use longer literal passwords then...

I have a mobile Core 2 Duo with 2 GHz. It tests about 2000 passwords per second.

[JohnDoe]

What about in-memory attacks? Using truecrypt, you will have parts of the file in-memory, and even in-swap, such that it could get on the hard-drive. Not to mention someone can sniff your Truecrypt password either keylogging it or in-memory. Even using a VM would do nothing to increase security, you must absolutely make sure you have no malware running on any outer OS layer from which you access your wallet from.

Woah, didn't know about that. I just might jump ship to GPG because of this new information (assuming GPG doesn't store my password in-memory too).

Good point about the secure deletion, but the solution to run an srm (or rm -P) on the file just seems easier to me than to install a whole other crypto framework.

By srm do you mean the shred command? Also I couldn't find the -P switch on the rm man page, what does it do?

[gene]

TrueCrypt's novel feature is the "deniable" filesystem. Bruce Schneier has published some work on it and stated that he "wouldn't trust it."

So we cannot break the deniability feature in TrueCrypt 6.0. But, honestly, I wouldn't trust it.

He doesn't seem to provide a reason to not trust it. I would take the direct statement of fact over his gut feeling.

Fair enough. But cryptology is more of a black art than anything else, and I trust Schneier's gut feeling more than most.

If you want to encrypt wallet files for backups, use GPG.
If you want to protect the wallet file from being stolen from your disk, use encrypted folders of the kind that your operating system provides. But don't expect it to be protected against malware while in use. Everything you have access to, the malware you catch has access to, too. It will protect you against people who steal your computer, but it will not protect you against malware.

Truecrypt will do *both*, if you set your .bitcoin directory to inside the container. To backup you simply copy the container. The wallet never touches the drive unencrypted, and there's no need to trust your operating system to do it right (EFS in Windows is breakable).

You can even have a fake wallet with the real wallet in a hidden volume. If the directory structure is the same, no traces will be left on-disk if you use the hidden one or not.

I like your paraphrasing.

Sure, TrueCrypt can do that. However, there are other reasons why I think it is inferior to PGP -- portability, standardization, existence of a commercial implementation, license, and the fact that it has been looked at long and hard since the cypherpunks of the 90s. GnuPG also doesn't require kernel module and it already installed in most (all?) current Linux distributions. Plus, we should be using it anyways.

What about in-memory attacks? Using truecrypt, you will have parts of the file in-memory, and even in-swap, such that it could get on the hard-drive. Not to mention someone can sniff your Truecrypt password either keylogging it or in-memory. Even using a VM would do nothing to increase security, you must absolutely make sure you have no malware running on any outer OS layer from which you access your wallet from.

Woah, didn't know about that. I just might jump ship to GPG because of this new information (assuming GPG doesn't store my password in-memory too).

To be fair, these same issues exist with other disk-encryption schemes, like filevault. If someone has a keylogger on your computer, you're sunk no matter what.

Good point about the secure deletion, but the solution to run an srm (or rm -P) on the file just seems easier to me than to install a whole other crypto framework.

By srm do you mean the shred command? Also I couldn't find the -P switch on the rm man page, what does it do?

Yes, I meant the local shred command. It depends of which UNIX or Linux you are using. Check your man pages to see which options apply.

[JohnDoe]

To be fair, these same issues exist with other disk-encryption schemes, like filevault. If someone has a keylogger on your computer, you're sunk no matter what.

I'm more concerned about the in-memory password storage and getting my computer stolen/seized when the power is on than having keyloggers/malware installed. Does GPG suffer from that too?

Yes, I meant the local shred command. It depends of which UNIX or Linux you are using. Check your man pages to see which options apply.

How many shred iterations would you consider "astronomically safe"?

[BombaUcigasa]

How many shred iterations would you consider "astronomically safe"?

One?

[gene]

To be fair, these same issues exist with other disk-encryption schemes, like filevault. If someone has a keylogger on your computer, you're sunk no matter what.

I'm more concerned about the in-memory password storage and getting my computer stolen/seized when the power is on than having keyloggers/malware installed. Does GPG suffer from that too?

Not in the same way. You can put

Code:

require-secmem

in your ~/.gnupg/gpg.conf to... well... require secure memory (not to be swapped). No matter, once it finished {en|de}crypting, gpg immediately forgets your passphrase, by default. It also uses some techniques that make bruteforcing take much longer.

Yes, I meant the local shred command. It depends of which UNIX or Linux you are using. Check your man pages to see which options apply.

How many shred iterations would you consider "astronomically safe"?

I just use the defaults. With such a small file, you can just go crazy and it still won't take too long.

[lonestranger]

At the risk of putting too fine a point on it, perhaps my "opacity" comes from your lack of reading comprehension.

Gene, I think the problem with GPG can be found right about here:

How to use GPG?

Code:

gpg --compress-algo BZIP2 --bzip2-compress-level 9 --encrypt -a -o text_crypt_wallet.txt wallet.dat

Say what now?

Of course, I anticipate that your response will be a sarcastic version of how stupid I am not to understand your code world, and I don't--so I must be stupid. But bitcoin's adoption is very, very threatened by this wallet problem and the advice they will encounter for it.  I know you are addressing a software audience with your gpg advice, but there are a lot of newbies coming in here seriously wanting to understand how to protect their investment, and the advice they encounter here is dreadful so far.

[gene]

At the risk of putting too fine a point on it, perhaps my "opacity" comes from your lack of reading comprehension.

Gene, I think the problem with GPG can be found right about here:

How to use GPG?

Code:

gpg --compress-algo BZIP2 --bzip2-compress-level 9 --encrypt -a -o text_crypt_wallet.txt wallet.dat

Say what now?

Of course, I anticipate that your response will be a sarcastic version of how stupid I am not to understand your code world, and I don't--so I must be stupid. But bitcoin's adoption is very, very threatened by this wallet problem and the advice they will encounter for it.  I know you are addressing a software audience with your gpg advice, but there are a lot of newbies coming in here seriously wanting to understand how to protect their investment, and the advice they encounter here is dreadful so far.

We have to use the best available tools, despite their limitations. Sometimes the command line does the job, and I gave cut-and-paste examples. Those options are not too cryptic, but that may be just because I have seen far more horrible examples for other programs. You didn't paste it, but I explained what these options do. Not sure what your beef is.

[bcearl]

To be fair, these same issues exist with other disk-encryption schemes, like filevault. If someone has a keylogger on your computer, you're sunk no matter what.

I'm more concerned about the in-memory password storage and getting my computer stolen/seized when the power is on than having keyloggers/malware installed. Does GPG suffer from that too?

My wallet management is meant to prevent that:
http://forum.bitcoin.org/index.php?topic=15068.0

Why my strategy is good?
1. As long as the special bitcoin user is not logged in, there are now key nor passwords in memory.
2. The bitcoin user only has to be logged in to make a transfer from the protected wallet. This is only a short time window.
3. As soon as the special bitcoin user is logged out, his protected data will be unmounted and everything is protected again.

The only way to get the keys out of that are the following:
1. You steal my computer physically while the special user is logged in.
2. You or the malware got root access while the special user is logged in.
3. You crack the special users password (12 characters of all types) or encryption keys (AES256).

[JohnDoe]

One?

Can you explain why? I don't know the low level mechanics of how files are stored on disk. The default of 3 overwrites and the very existence of an iterations switch leads me to believe that multiple versions of the same file may be remembered, even after 'deletion'.

Not in the same way. You can put

Code:

require-secmem

in your ~/.gnupg/gpg.conf to... well... require secure memory (not to be swapped). No matter, once it finished {en|de}crypting, gpg immediately forgets your passphrase, by default. It also uses some techniques that make bruteforcing take much longer.

Cool, thanks.

My wallet management is meant to prevent that:
http://forum.bitcoin.org/index.php?topic=15068.0

I'll look into it.