GnuPG versus TrueCrypt

[allinvain]

i use AxCrypt and it does a very cool job , very easy.

That's what I use too, but I'd like a version for linux. Not sure if they'd ever come up with one. I guess Truecrypt is the way to go in Unix land.

[1713567344]

1713567344

[1713567344]

1713567344

[bcearl]

i use AxCrypt and it does a very cool job , very easy.

That's what I use too, but I'd like a version for linux. Not sure if they'd ever come up with one. I guess Truecrypt is the way to go in Unix land.

No, GPG is the way to go in Unix land. GPG is installed on every proper Unix system anyway. On the other hand, Linux Distros reject including TrueCrypt into their repositories for a variety of reasons.

Why use a unsupported tool, which you also have to install and update yourself, if there is a widely well-known tool available by default, where the distributor takes care of discovered vulnerabilities and updates?

[marcus_of_augustus]

Question for GPG knowledgeable;

GPG symmetric encryption of the wallet.dat with Blowfish algo, i.e.

Code:

$gpg --cipher-algo  BLOWFISH -c wallet.dat

is how much different than just using bcrypt?

Code:

$bcrypt wallet.dat

(Besides that gpg doesn't wipe the raw file off the disk as bcrypt does.)

Any program that uses that algorithm properly should be secure, but you have to look at the details.

The encryption algorithms work with binary keys that must be random to ensure security. If you encrypt a file, you usually do it with a password. A password is not a secure key in that sense, so the algorithm also has to derive a binary key from the password where each bit has a probability of 0.5.

Example:
- you have a file and want to encrypt it with AES256
- AES256 needs a 256 bit random key
- you choose a strong password of 12 ascii characters

Problem:
- your password is only 12 * 8 = 96 bits long
- the most significant bit of each byte is 0, because it's ASCII
- because of that, you should not use your password as AES key directly

There are different solutions now, and they really matter. That's why I would prefer GPG: It has been around for a long time, it is well tested, and the authors are experts who know the state of the art methods to derive keys from passwords.

I have looked at 7z and they seem to use a good key derivation method, too. That was the point I was skeptical about. It could be that compression tool programmers don't care so much or are just not that well informed about state of the art techniques in the crypto community.

So basically you don't know if/what "bcrypt" does anything different than "gpg --cipher-algo BLOWFISH"?

[bcearl]

So basically you don't know if/what "bcrypt" does anything different than "gpg --cipher-algo BLOWFISH"?

Yes, I never heard of it. I think I personally wouldn't trust anything other than GPG and OpenSSL. But that's because I know them and I know that they are well reviewed. There can be tools with similar standards that I just don't know of.

[harm]

Hi,
I found this discussion very interesting as I asked the question myself.
Maybe anyone has already mentioned it, but how do you protect /tmp files or what so ever?

You need to decrypt your wallet to the .bitcoin directory, or any other place where the blockchain is.
After that you encrypt your wallet again and delete the unencrypted wallet.

Do you use an eraser tool for that? Otherwise it would not be safe enough for me;)

For me I figured out to use a truecrypt container holding my .bitcoin directory.
To backup the wallet only I use pgp and ssh (rsnapshot) to put it on a remote computer.

[jayfitt]

Hi,
I found this discussion very interesting as I asked the question myself.
Maybe anyone has already mentioned it, but how do you protect /tmp files or what so ever?

You need to decrypt your wallet to the .bitcoin directory, or any other place where the blockchain is.
After that you encrypt your wallet again and delete the unencrypted wallet.

Do you use an eraser tool for that? Otherwise it would not be safe enough for me;)

For me I figured out to use a truecrypt container holding my .bitcoin directory.
To backup the wallet only I use pgp and ssh (rsnapshot) to put it on a remote computer.

On linux use the shred command and then delete it:

Code:

shred wallet.dat
rm wallet.dat

EDIT: According to this thread, shred may not do it's job properly...

[harm]

nice, didn't know that one;)


Now I am asking myself how sensitive the gpg private key is.
The process is to unlock the private key with my personal password. This private key then decrypts the file, thas was encrypted with my public key.
How hard is it do derive my personal password from the private key compared to hacking a symmetric gpg key?

[riceberry]

I use gnupg for my wallet but I also have a trucrypt volume where I store some other materials

I use this to automate the process just prompting for password when opening and then upon closing bitcoin to encrypt it again

seahorse-tool -d ~/.bitcoin/wallet.dat.pgp && /bitcoin-0.3.23/bin/32/bitcoin && rm ~/.bitcoin/wallet.dat.pgp && seahorse-tool -e ~/.bitcoin/wallet.dat && rm ~/.bitcoin/wallet.dat

[netrin]

Versioned backups let me sleep soundly at night. I commit all of my symmetrically encrypted wallets into a git repository (any version control system will work, though DVCS have advantages), commit locally after every use and push/sync/replicate periodically.

TrueCrypt will likely expose all of your keys during each use, whereas encrypting individual wallets puts your eggs into multiple lighter baskets. It is my belief that bitcoin is not yet ready for users uncomfortable with the command line, which to me is synonymous with yet unfounded one-click security expectations.

[marcus_of_augustus]

It is my belief that bitcoin is not yet ready for users uncomfortable with the command line,

I agree.

It should be the first question someone asks an exchange before committing funds ... "do you have someone on your team who can do CLI encryption and bitcoind calls?"