GnuPG versus TrueCrypt

[ctoon6]

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.

If your worried about remnants of files on your disk you don't want, I have only 1 word for you, dban.

If its good enough for the department of defense, its good enough for me

edit: and not destroy your hard drive.

[bcearl]

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

For software, one iteration is enough. You cannot find data by software then.


But forensic investigators can open your disk and analyze it with much smaller tools than the read/write heads of the hard disk. They can find tiny trails of data that aren't physically overwritten completely.

[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 am really interested in what your strategy was. Because I really did not put much effort in it. I just took the first tool Google gave me.

Maybe the high performance has something to do with the fact that I have a SSD? I tried to run the tool on a university machine with 32 CPUs and it was way slower there.

Then I just created a 10 MB tmpfs (a folder that is stored in RAM instead of disk), and it went even faster (2400+ tests per second).

I am at "d3x2x" now, but still not lucky. But be patient, I want to crack it!

[BombaUcigasa]

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

Modern hard drives (not the ones made 20 years ago) are using perpendicular storage and very small magnetic domains, not to mention they actually STRUGGLE reading the actual encoded data that you actually wrote last time in there (older drives will have decayed read speeds on very used areas). Overwriting an area with new information encoded using Solomon-Reed algorithms and parity check codes will make any part of a small spot of information impossible to decode if one part of it is too faint especially since a single byte is spread over several tens of encoded bits. Also hard drives will employ spare sectors to replace useless ones in the track. Wiping a file area with zeroes, will not fill in the space with actual unidirectional magnetic flux but with a sequence of seemingly random magnetic variations based on the algorithms used. Even writing a single modified bit on a hard drive will cause the controller to read the whole sector, re-encode the sector and write out a whole new magnetic pattern. Should you be able to detect the previous faint pattern, how would you tell which previous "version" you are reading, based on the bit-flip options available (same bit up, same bit down, inverted up, inverted down)?



To actually recover faint imprints of previous recordings you would need to use a custom made controller that is compatible with the existing commercial version, but is able to read magnetic patterns with increased frequency and quality. Such a device would exceed the cost that hard drive manufacturers require to design a hard drive controller, running into the millions, just to attempt and recover a possibly one-pass deletion.

Many people have asked data recovery firms for a quote on a data recovery job after they explained they zero-filled the drive by mistake, and their request was refused as no commercial company is able to successfully recover data from a low-level format. If you are not convinced that one pass can delete the data for generic uses, destroy the thing by cooking it over the magnetic hysteresis. Kill it with fire, the only way to be sure.

[phillipsjk]

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

If the file is really overwritten, one iteration should be enough on modern magnetic disks. If the file is not really overwritten, extra iterations don't help much.

The filesystem can move files around or save old versions of files as they are overwritten. In theory, this is under OS control.

The Hard-disk controller can also move sectors around without your or the OS's knowledge. Magnetic disk will do this when they detect that a sector is failing. SSD's will do this for performance reasons (but likely delete the data anyway). Single-level SSDs may need more than one pass of random data to really guarantee the data is really unrecoverable (the floating gates degrade in a predictable manner during writes).

To avoid those problems, I recommend just using full-disk encryption. Shredding tools can then be used to delete even the encrypted copy of a file. I also trust dban, even in the face of an untrustworthy hard-disk controller; assuming "extra" hidden capacity is less than capacity visible to the OS. The pseudorandom write pass is uncompressible data: the drive can't "cheat" by saving a compressed copy of the sensitive data. The verify pass checks that the uncompressible data was really written to disk. The zero pass is compressible, but otherwise hides the pseudorandom data used. The exceedingly paranoid may want to do a second pseudoramdom write/verify, then destroy the disk.

[BombaUcigasa]

I am really interested in what your strategy was. Because I really did not put much effort in it. I just took the first tool Google gave me.

Maybe the high performance has something to do with the fact that I have a SSD? I tried to run the tool on a university machine with 32 CPUs and it was way slower there.

Then I just created a 10 MB tmpfs (a folder that is stored in RAM instead of disk), and it went even faster (2400+ tests per second).

I am at "d3x2x" now, but still not lucky. But be patient, I want to crack it!

I don't understand why filesystem performance should affect such a small file, it should only depend on the processing power. My strategy was to make the password be found by brute-force attacks a bit after 35^5/2 tries. I see it does take a bit of time for a 5 characters password, I usually go with passwords with more than 8 characters these days for accessibility reasons, looking forward to increase that to over 90 bits of entropy per password by using 14 or more characters. To get the equivalent of a 256-bit unique key, you would need to use the whole alphabet twice, numbers and punctuation in a password of no less than 40 characters. Enjoy typing your 40 character password or accept lower security

[Nesetalis]

i generally go with pass phrases. Sections of songs, poems, or quotes. I seriously hate sites that put a maximum size on a password under 20 characters.

[bcearl]

I am really interested in what your strategy was. Because I really did not put much effort in it. I just took the first tool Google gave me.

Maybe the high performance has something to do with the fact that I have a SSD? I tried to run the tool on a university machine with 32 CPUs and it was way slower there.

Then I just created a 10 MB tmpfs (a folder that is stored in RAM instead of disk), and it went even faster (2400+ tests per second).

I am at "d3x2x" now, but still not lucky. But be patient, I want to crack it!

I don't understand why filesystem performance should affect such a small file, it should only depend on the processing power. My strategy was to make the password be found by brute-force attacks a bit after 35^5/2 tries. I see it does take a bit of time for a 5 characters password, I usually go with passwords with more than 8 characters these days for accessibility reasons, looking forward to increase that to over 90 bits of entropy per password by using 14 or more characters. To get the equivalent of a 256-bit unique key, you would need to use the whole alphabet twice, numbers and punctuation in a password of no less than 40 characters. Enjoy typing your 40 character password or accept lower security

It should not depend - but it does. One explanation may be that 7zip is a crappy piece of software.

[nathanrees19]

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.

The deniable wallet is a killer feature for me. Any non-functional advantages of PGP are less important.

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

Hai guise, did anyone crack this yet? I said it would take days, you said it would take hours, so far it took days. I can make it interesting, like putting a valid wallet with some bitcents in it if that would raise your interest.

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

Hai guise, did anyone crack this yet? I said it would take days, you said it would take hours, so far it took days. I can make it interesting, like putting a valid wallet with some bitcents in it if that would raise your interest.

Yeah, I admit that I gave up, I didn't have enough patience.

The tool tested all 5-character-passwords and did not find any match. I didn't want to invest any more effort, the computer went hot all night.

[bitcola]

This discussion is moot. Thanks to the publicity, within a few days someone will create a new client that has encryption built-in. I'm quite sure of it.

[MysteryMiner]

Original Poster don't understand that:

1. TrueCrypt and GNUPG have different goals and modes of operation. TrueCrypt is for encrypting storage, GnuPG is for encrypting e-mail.

2. TrueCrypt is source available and the format specification is well known. No need for NSA certification to be usable

3. The encryption will not protect if computer is infected with malware, unless the encryption prevents you from acessing your wallet as well.. It might help only if computer is stolen in powered down mode.

That crypto uncle with beard in that link does not understand what deniable encryption is for and how it operates. I bet he did not read the TrueCrypt manual and FAQ before made his conclusion. People sometimes do such things. I myself heard about Bitcoins in 2010 and immediately refused them because it instantly associated with such crappy software as Bitcomet, Bitlocker and Bitlord. I tought they are some PayPal or e-gold clone and most likely a scam also. I started to use them, mine them and steal them only when I read the whitepaper by Satoshi.

[bcearl]

This discussion is moot. Thanks to the publicity, within a few days someone will create a new client that has encryption built-in. I'm quite sure of it.

It was always planned, it's just that you can't get everything finished at one time. It's not the case that the bitcoin software was released - it is more of an accident that the media attention came so early.

[bcearl]

2. TrueCrypt is source available and the format specification is well known. No need for NSA certification to be usable

Why do all serious Linux distros reject TrueCrypt?

[MysteryMiner]

2. TrueCrypt is source available and the format specification is well known. No need for NSA certification to be usable

Why do all serious Linux distros reject TrueCrypt?

Because the restrictions TrueCrypt licence puts on distributing recompiled TrueCrypt versions. And Linux nerds taking licences and freedom too seriously.

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

Hai guise, did anyone crack this yet? I said it would take days, you said it would take hours, so far it took days. I can make it interesting, like putting a valid wallet with some bitcents in it if that would raise your interest.

Yeah, I admit that I gave up, I didn't have enough patience.

The tool tested all 5-character-passwords and did not find any match. I didn't want to invest any more effort, the computer went hot all night.

Sorry to hear that, if the tool really tested the 5-character passwords as described and did not find "s3krt" as the password then it was either broken (in which case a cracker needs to be sure he uses the right protocol, I understood slower speeds are to be expected when bruteforcing 7zip) or it was used incorrectly. Either way, it doesn't matter as using a long password on the 7zip is a good way to secure your wallet. I say this because it's accessible (easy to use, well integrated, fast), cheap (small and open source, doesn't create files bigger than needed like Truecrypt) and secure (requires serious expenses to crack the password).

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

[bcearl]

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.

[PGPpfKkx]

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