Topic: GnuPG versus TrueCrypt - page 3. (Read 28802 times)

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...

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.

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.

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

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.

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.

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.

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?

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.

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.

I reject what?

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?

No. It does not improve anything at all. It demonstrates a deep misunderstanding of these tools and their limitations, and that you are happy to promulgate dangerous advice to others.

It is well understood that a 5 character password (even using a larger characterspace) is total shit. What you think is immaterial. Such a short password is literally nothing to an even moderately-motivated attacker. It is worse than putting a luggage padlock on a 10 ton door to a steel vault.

What is most laughable is that the cost of increasing the keylength is basically nothing, much like using the proper tools. Yet you reject even the most rudimentary advice for... well... no apparent reason.

I'll consider a small donation for the good of the community considering that it improves our security, especially since I think this little 294 bytes archive could be broken in 2 months, and not 24 hours.

This would be far more interesting (and would make the point a bit more clear) if you did this with a wallet holding all your BTC.

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 wouldn't be encrypted. Examine the title of the thread.

Laser engraving on a metal plate would be better

Sorry for being "opaque."


Please note the part where I specifically give an example of using a symmetric algorithm by itself (no public/private keypair required). And the subsequent posts where I repeated this. No offense taken...

Quote

Whoa there!  What do you mean?  Why would I just happen to HAVE a GPG key?  Where would it come from? But not having to mess with keypairs is an advantage anyway.

See above.

Quote

So I now need to scan a printout with character recognition software....you truly live in a different world than most people. No offense you brilliant tech head but this situation is terrible.

No. You don't need to do it, at all. Nowhere did I state that this is a requirement. It seems obvious that this is an optional step for those who wish to have a secure hardcopy of the intact wallet.dat. If this isn't clear, then I would agree that we do live in different worlds.

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

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