Bitcoin Forum

I see many people recommending TrueCrypt for backing up and securing wallets. I think it is important to protect wallets, but I suggest that GnuPG (http://www.gnupg.org) would be the better tool. As BTC become increasingly valuable, it becomes more and more important to use the best tools to protect your stash.

GPG is more than a tool facilitating symmetric crypto. It is a standardized and well-tested suite of tools that permit encryption/signing of arbitrary data such as files and email (http://enigmail.mozdev.org/). Basically, anyone looking to get deeper into the bitcoin economy (http://wiki.bitcoin-otc.com/wiki/GPG_authentication) would be well-advised to understand and use GPG to develop and maintain a cryptographically strong reputation. TrueCrypt just isn't as flexible. GPG also follows an established standard (http://www.ietf.org/rfc/rfc4880.txt), and it interoperable with commercial software (http://www.symantec.com/business/theme.jsp?themeid=pgp). TrueCrypt does not. TrueCrypt also isn't available for nearly as many platforms as GPG.

TrueCrypt's novel feature is the "deniable" filesystem. Bruce Schneier has published some work on it and stated that he "wouldn't trust it." (http://www.schneier.com/blog/archives/2008/07/truecrypts_deni.html)

Then there is the small matter of licensing. GnuPG is licensed under the GPL. TrueCrypt has a non-free license.

From http://en.wikipedia.org/wiki/Truecrypt#Licensing


How to use GPG?


This will compress and then encrypt your wallet using your private GPG key. The -a flag tells gpg to give you ascii-armored (printable) output. The -o flag tells gpg to name the output file "text_crypt_wallet.txt". You can then print this out. The file will look something like this:


I recommend first moving bitcoins to a fresh wallet with a single address via a single transaction, so as to have as small a file as possible. Otherwise, you may end up with many pages of output.

Make sure the font is OCR-readable (http://en.wikipedia.org/wiki/Optical_character_recognition) and large enough to avoid scanning and transcription errors. Also, make sure to keep track of page numbers.

If you don't have a GPG key, you can encrypt it via just a symmetric cipher and password:


Just don't forget your password.

By default, GPG uses CAST5 as the symmetric cipher. Note that you can always specify which symmetric cipher you want to use (all of gpg's ciphers are considered strong) with one of these flags:


To recover the wallet, you can scan the document and OCR it to a file. Then decrypt it:


If you are running GNU/Linux, you probably already have GnuPG If you have windows, you can get GnuPG here: http://www.gpg4win.org/

one of the problems with using gpg, is you also have to backup your public and private key. The most likely scenario where you need to recover a backed up wallet, is if your computer has crashed. Truecrypt can allow you to decrypt something with simply a password or a keyfile or both. also, true crypt allows that if some one gets access to your computer, they cant just find your public/private key pair and unlock your wallet... (unless you of course save the decryption key in truecrypt like a dumbass)

What I personally do, is store my gpg keys and my wallet in a truecrypt volume, then email that volume to myself, to store it in 3 places, sent computer, web based email service, and recieved computer. then use a 50+ character passphrase to gain access.

Note that you can use symmetric encryption by itself. See above. No need to use a public key in that instance.

whats wrong with 7zip and use a password with a .7z archive?

this is true, I always forget about that feature since I never touch it. Almost the entirety of my PGP/GPG use is email and sharing files via http

Depends on how it does the encryption. Maybe they also have a good AES256 implementation. Maybe it's crap.

I wouldn't trust a tool originally designed for compressing data to safely encrypt data. GPG exists for protecting data. Also, PGP has been around for a long time. It is well-understood and has been reviewed for flaws. It is also far more flexible than things like encrypted zip/7zip files.

Encryption is hard to properly implement. GPG has earned quite a bit of trust in the community for a reason.

7zip uses AES-256 and all you have to do is right click on the file and click "add to archive" and set your password in the box. takes only 2minutes from installing 7zip to having your wallet.dat file encrypted.

WARNING TO DROPBOX USERS
if you have ever stored an unencrypted version of your wallet file inside dropbox and deleted it, it still exists in your dropbox account unless you specifically delete it from the history.

Nothing. As long as you use AES-256 and encrypt the file listing too.

You do realize they keep backups of your account up to 30 days (officially), this including whole snapshots of permanently deleted files? And if they wanted to get your wallet while you had it, they could. Better just transfer everything to a new wallet and save that.

It's not enough to use AES256, you have to use it without flaws.

it would be nice if you said why 7zip is no good, pgp was designed to send data securely, so using it for personal secure storage seems redundant to me. the only use i see pgp for is sending a file to someone else to prevent interception both ways, in this case 7zip would be no good unless the password was given in person, but pgp is good because its like sending an unlocked padlock for the other person to...wait you all probably know this story.

While we're on this subject; here's the script I call from a cron job, in case it is of use to others...


It's not ideal because of the use of a temporary; but I don't know a way of getting bitcoind to dump to standard out.

GPG does also provide encryption of files with symmetric algorithms and passwords. You don't have to use public key crypto for that application.

Then why use GPG if you end up only needing a password.

Because it is known to use well known algorithms properly, and it is way simpler (by this I mean how it works, not only how to use it) than TrueCrypt.* Read the OP, please.

I have tried to crack one of my passwords on a 7-zip container just for fun. I had a 3 keys/second generation performance for a 5000 MIPS CPU. Even a 5 chars password would take 20 years to crack my that CPU. Since you could use GPUs, you could lower that to maybe 2 months? Just to break a wallet. I suppose it should have more than 50 BTC to be worth it...

Use a sufficiently long password and you should be ok for now. It's an easy method of saving your wallet as it doesn't require you to store keys and whatnot.

You can use it with or without a public/private key pair. You can use it for files, emails, digital signatures, etc. It is a more flexible tool which you are almost certainly going to need anyways to take full advantage of the bitcoin economy. It also works reliably across basically all platforms.

OpenPGP is a real standard, which stipulates not only the ciphers (AES128, AES256, etc) but also the modes (ECB, CBC, etc). There is no RFC standard for the crypto in tools like 7zip. The way the ciphers are implemented is as important as the cipher itself. Like I said above, there is a reason why GnuPG is such a highly-regarded encryption suite.

7zip is just not a tool designed for encryption. GPG is.

What exactly did you test? Why should an attacker try to decrypt the 7zip-file to get the password? There are certainly better ways!

i use windows, and gpg is mostly Linux, i did get it to work when i was using it a month or so back, but it generally was an unstable piece of software, it crashed often when certain functions were used, it was not my machine either because i used it inside a VM as well. 7zip on the other hand work flawlessly and decompresses almost all archive types. and you also have to take into account for how long the data needs to be kept safe.  even if it is only good for a month, its still good enough because i don't have the same wallet for that long. in the case of bitcoin you have another factor as well, the keys used for the wallet may actually be less secure or take less time to crack than the encryption on the wallet.

aye I use gpg4win and it crashes constantly :p thankfully the crashes dont screw me over, just make me take a bit longer to do stuff.

there's nothing i hate more than good software that crashes.

I wasn't aware of that, I have had no Windows for years now.

7zip seems to use AES256, that may be ok. But you have to choose a strong password, the 5 characters, that somebody suggested, are way too small. I am talking about 12 or more charakters, which are from different types and are not corresponding with dictionary words or keyboard patterns.

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

This is trivial to bruteforce (~1.0e8 possibilities). Get yourself a longer password.

I have only used gpg4win via cmd.exe. No problems for me. Running windows is another issue altogether...

Of course, use whatever tools you are most comfortable with. Just realize that not all crypto is created equal. Caveat emptor. When wallets start holding tens of thousands of dollars worth of BTC, I would not trust an archiver.

when the stakes are that high i would not either.

i would have all my coins split into 3 separate wallets on 3 separate servers on 3 separate continents.

Oh my but I must lament once again how horrible this wallet problem is! Bitcoin's reputation is going to get creamed in the media until this is solved. You brilliant tech heads have a monster by the tail. So now let me slog through one of your opaque posts here, parsing and probing to uncover the nugget of truth for the uninitiated (like ME) to put to use...


Whoa there! I have used gpg in thunderbird to encrypt email but using it in my operating system is new to me because for one thing, at what point did I generate a key pair? Where is this private key?  Another observation is that though you criticize truecrypt, at least it has a visual interface instead of this command line shit. Sorry if this offends...


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.


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.

You do not have to print your encrypted file and scan it in later. However, plain paper is the most durable medium available for long-term data storage, so it will be useful in some circumstances.

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

Sorry for being "opaque."


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


See above.


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.

Laser engraving on a metal plate would be better :)

It wouldn't be encrypted. Examine the title of the thread.

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.

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.

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.

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.

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?

I reject what?

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.

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.

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?

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.

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.

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.

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

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.

He doesn't seem to provide a reason to not trust it. I would take the direct statement of fact over his gut feeling.


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.

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.

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


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?

Fair enough. But cryptology is more of a black art than anything else, and I trust Schneier's gut feeling more than most.


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.


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.


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.

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?


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

One?

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.


I just use the defaults. With such a small file, you can just go crazy and it still won't take too long.

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.

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.

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

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.

If your worried about remnants of files on your disk you don't want, I have only 1 word for you, dban (http://www.dban.org/).

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

edit: and not destroy your hard drive.

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.

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!

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

http://upload.wikimedia.org/wikipedia/commons/0/06/MFM_AFM_JANUSZ_REBIS_INFOCENTRE_PL_HDD_MAGNETIC_MEMORY_EVOLUTION.png

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.

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.

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 :D

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.

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

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

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.

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.

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.

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.

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.

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

Question for GPG knowledgeable;

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


is how much different than just using bcrypt?


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

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?

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.

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:


EDIT: According to this thread (http://bitcointalk.org/index.php?topic=18609), shred may not do it's job properly...

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?

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

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.

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?"