Bitcoin Forum
December 03, 2016, 03:56:14 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 [3] 4 5 »  All
  Print  
Author Topic: GnuPG versus TrueCrypt  (Read 26996 times)
BombaUcigasa
Legendary
*
Offline Offline

Activity: 1414



View Profile
June 13, 2011, 03:04:01 PM
 #41

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.
1480780574
Hero Member
*
Offline Offline

Posts: 1480780574

View Profile Personal Message (Offline)

Ignore
1480780574
Reply with quote  #2

1480780574
Report to moderator
1480780574
Hero Member
*
Offline Offline

Posts: 1480780574

View Profile Personal Message (Offline)

Ignore
1480780574
Reply with quote  #2

1480780574
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
gene
Sr. Member
****
Offline Offline

Activity: 252


View Profile
June 13, 2011, 03:13:02 PM
 #42

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.

*processing payment* *error 404 : funds not found*
Do you want to complain on the forum just to fall for another scam a few days later?
| YES       |        YES |
kwukduck
Legendary
*
Offline Offline

Activity: 1564


View Profile
June 13, 2011, 03:28:43 PM
 #43

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?



14b8PdeWLqK3yi3PrNHMmCvSmvDEKEBh3E
Nesetalis
Sr. Member
****
Offline Offline

Activity: 420



View Profile
June 13, 2011, 04:06:51 PM
 #44

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.

ZOMG Moo!
gene
Sr. Member
****
Offline Offline

Activity: 252


View Profile
June 13, 2011, 04:28:13 PM
 #45

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.

*processing payment* *error 404 : funds not found*
Do you want to complain on the forum just to fall for another scam a few days later?
| YES       |        YES |
bcearl
Full Member
***
Offline Offline

Activity: 168



View Profile
June 13, 2011, 04:33:55 PM
 #46

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.

Misspelling protects against dictionary attacks NOT
jhansen858
Sr. Member
****
Offline Offline

Activity: 336


View Profile
June 13, 2011, 05:09:55 PM
 #47

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

Hi forum: 1DDpiEt36VTJsiJunyBc3XtG6CcSAnsQ4p
jhansen858
Sr. Member
****
Offline Offline

Activity: 336


View Profile
June 13, 2011, 05:14:00 PM
 #48

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.

Hi forum: 1DDpiEt36VTJsiJunyBc3XtG6CcSAnsQ4p
nathanrees19
Full Member
***
Offline Offline

Activity: 196



View Profile
June 13, 2011, 05:25:04 PM
 #49

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

Quote from: Bruce Schneier
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
Legendary
*
Offline Offline

Activity: 1414



View Profile
June 13, 2011, 05:30:27 PM
 #50

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
Full Member
***
Offline Offline

Activity: 168



View Profile
June 13, 2011, 05:38:52 PM
 #51

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.

Misspelling protects against dictionary attacks NOT
JohnDoe
Sr. Member
****
Offline Offline

Activity: 392



View Profile
June 13, 2011, 05:55:54 PM
 #52

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
Sr. Member
****
Offline Offline

Activity: 252


View Profile
June 13, 2011, 06:28:58 PM
 #53

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

Quote from: Bruce Schneier
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.

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

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

*processing payment* *error 404 : funds not found*
Do you want to complain on the forum just to fall for another scam a few days later?
| YES       |        YES |
JohnDoe
Sr. Member
****
Offline Offline

Activity: 392



View Profile
June 13, 2011, 06:46:17 PM
 #54

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
Legendary
*
Offline Offline

Activity: 1414



View Profile
June 13, 2011, 07:01:41 PM
 #55

How many shred iterations would you consider "astronomically safe"?
One?
gene
Sr. Member
****
Offline Offline

Activity: 252


View Profile
June 13, 2011, 07:06:15 PM
 #56

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.

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

*processing payment* *error 404 : funds not found*
Do you want to complain on the forum just to fall for another scam a few days later?
| YES       |        YES |
lonestranger
Member
**
Offline Offline

Activity: 115


I like long walks on the beach, shaving my head...


View Profile
June 13, 2011, 07:19:31 PM
 #57

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
Sr. Member
****
Offline Offline

Activity: 252


View Profile
June 13, 2011, 07:33:29 PM
 #58

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.

*processing payment* *error 404 : funds not found*
Do you want to complain on the forum just to fall for another scam a few days later?
| YES       |        YES |
bcearl
Full Member
***
Offline Offline

Activity: 168



View Profile
June 13, 2011, 07:53:48 PM
 #59

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

Misspelling protects against dictionary attacks NOT
JohnDoe
Sr. Member
****
Offline Offline

Activity: 392



View Profile
June 13, 2011, 07:56:25 PM
 #60

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.
Pages: « 1 2 [3] 4 5 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!