Fast File Encryption for Windows?

cryptoz wonders: "I've used numerous encryption applications for both Windows and Linux over the past few years and have always been satisfied. Until I realized I needed to start encrypting large files (say 10 to 30 GiB), or at least a large number of small(er) files. I found that everything I use seems to take hours and hours to compress, encrypt and shred. Not to mention decompressing, decrypting and deleting on the other end. Every web search I do on the topic seems to turn up mostly closed-source applications or snake oil, neither of which is acceptable. Does Slashdot have any suggestions for fast file encryption? I should make it clear that in my particular case, I do not need to have a perfect key or incredibly secure encryption, since it is not the weakest link (as I am susceptible to hardware key-loggers, CRT eavesdropping and the like). The encryption needs to be just strong enough, but most importantly, *fast*." This is a worthwhile question, but when dealing with files in the 10s of GB, can anything really be considered to be "fast"?

Comments

Isn't TrueCrypt Linked in the POSTING?

[neonprimetime]

Ok ... is it just me, or is TrueCrypt linked IN THE FREAKIN' POSTING ABOVE? Why is everybody's answer of "TrueCrypt" getting modded as informative?

-1, Pedantry

[Gothmolly]

GiB? Dude, just say GB, we all get it. It's a buttload of data.

Re:-1, Pedantry

[Lord Ender]

"1. Because GB is a more well known shorthand for a data amount."

That is a reason TO use GiB. It promotes awareness so that there is no confusion when it DOES matter.

"2. Because a difference of 73,741,824 bytes doesn't matter in this article."

Um... that supports the argument that it doesn't matter one way or the other which one is used, making the initial complaint seem pointless.

Security costs CPU cycles

[Ckwop]

I found that everything I use seems to take hours and hours to compress, encrypt and shred. Not to mention decompressing, decrypting and deleting on the other end.

XOR against a repeated key would be ultra-fast but woefully insecure. When will people learn that it takes CPU cycles to encrypt that much plain-text? In just about every other field you don't get something for nothing; why should Cryptography be any different?

Simon

Are you sure it's the encryption?

[cow-orker]

Assume a sustained transfer rate of 30MB/s, which is quite good for a single hard disk. You won't get that much when transferring lots of small files. Reading 30GB takes 1000s or about 18 minutes, writing it back another 18 minutes, doing both takes longer, because interleaving both processes will lower the transfer rate. If you're shredding the old data, you can add in another 20 minutes per pass. So encrypting 30GB takes 60 minutes, probably a lot more, and there's nothing you could do about it in software.

Encryption itself... I seem to remember that TwoFish needs 26 clocks to encrypt 8 bytes on a Pentium. So your 2.6GHz CPU can encrypt 8GB/s (but the bus cannot deliver that much, I suspect). Add in some fudge factors for OS overhead and other tasks, and you're still two orders of magnitude below the IO time.

You need faster disks.

Re:Are you sure it's the encryption?

[WuphonsReach]

Encryption itself... I seem to remember that TwoFish needs 26 clocks to encrypt 8 bytes on a Pentium. So your 2.6GHz CPU can encrypt 8GB/s (but the bus cannot deliver that much, I suspect). Add in some fudge factors for OS overhead and other tasks, and you're still two orders of magnitude below the IO time.

BTW, TrueCrypt includes a little benchmark tool to allow you to calculate throughput rates for the various algorithms (as implemented inside of TrueCrypt). Useful for seeing just what the best-case rates are for a particular CPU. On the Opteron 246, they stack up as:

Blowfish (47) > Twofish (41) > CAST5 (35) > Serpent (34) > AES (33) > Triple-DES (12)

Where (NN) is the mean speed in megabytes/sec for encryption/decryption rates. Your data rates will vary on other CPUs and on other motherboards.