Topic: GnuPG versus TrueCrypt - page 2. (Read 28723 times)

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.

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

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

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.

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

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.

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.

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!

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.

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.

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


Cool, thanks.


I'll look into it.

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

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.

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


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.

Not in the same way. You can put 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.


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