Slashdot Mirror
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"?
I'd say your best bet'd be TrueCrypt.
You linked to it yourself, so you should be aware of the strengths of the application. It does on-the-fly disk encryption with either whole partitions or disk image files, has absolutely no problem with massive disks (I have a 40GB image on a USB drive), and is pretty fast. My benchmarks come up with 50MB/s average throughput (around 56MB/s encrypting, 47MB/s decrypting) for 256bit AES encryption on my machine. TrueCrypt seems to cope well with files of any size, and while I can't say I've tried 30GB, 4.7GB DVD images work very well indeed.
One thing that really makes it stand out in your scenario is the ability to use keyfiles. This allows you to select one or more files that will be used (hashed?) with your password to secure your data against those hardware keyloggers. (Although, I would question whether encryption is really required if you aren't that bothered about security.)
The best part of TrueCrypt is that it is completely open-source. No closed/proprietary systems and no snake oil. For encryption on Windows, when the built in stuff doesn't cut it, TrueCrypt is the only way to go, IMHO.
But you should look at TrueCrypt
The Statue of Liberty is America's lawn jockey.
Yes, a station wagon filled with tapes of 10GB+ files doing 80mph on a highway is going at a pretty fast clip in my opinion. YMMW.
With apologies to AS Tanenbaum.
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
Ever tried this? SureCrypt
SureCrypt is an ultra small encryption program designed for fast processing of extremely large files. It can encrypt or decrypt files as fast as Windows Explorer can copy them. SureCrypt presents a flexible user interface with detailed record of all operations.
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?
I suggest getting some hardware acceleration: the VIA EPIA boards use electrical interference in their traces to suppy entropy to a hardware encrypt/decrypt enginge that can achieve 25 Gb/s encryption. This is a 1.0GHz passively-cooled board with SATA ports, hardware MPEG2 decoding and all on a 17x17 cm^2 board.
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.
The submitter's question linked to truecrypt as one of two programs he's tried and found not fast enough. I hear it's real nice, but he's already found it too slow for his needs.
I'm also amused by the submitter's "too slow" comment for TrueCrypt. I use it on my 4-year old laptop (a 1.7Ghz Pentium 4 mobile) and find that it's the hard drive that is the bottleneck rather then the CPU. I'm using the stock TrueCrypt settings for encryption algorithm (256bit AES, LRW mode) and hash (RIPEMD-160). I have two volumes on the laptop, one is a ~700MB TrueCrypt file volume used for extra sensitive data and the second is a full-disk encrypted FireWire drive attached to the unit (160GB).
Copying from the laptop's hard drive to the encrypted external FireWire drive gives me transfer rates of around 10-12MB/sec and uses up around 30% of my CPU. Which is not too shabby for a 4 year old laptop. I would hardly call it "too slow".
I just did the benchmarks for a 100MB buffer, the left number is speeds on my 1.7Ghz Pentium 4 mobile laptop CPU, on the right is performance of a 2Ghz Opteron 246 chip (TrueCrypt 4.2 is not multi-threaded so it only used one of the two chips installed in that system):
Blowfish 35.1MB/s 46.8MB/s
Twofish 21.3MB/s 40.6MB/s
AES 28.5MB/s 32.6MB/s
Serpent 11.7MB/s 34.3MB/s
CAST5 10.5MB/s 34.7MB/s
Triple-DES 6.2MB/s 12.0MB/s
Those are not scientificially rigorous tests, but the built-in benchmark tool shows that the laptop's P4 is capable of very high encrypt/decrypt rates. It also looks like Serpent/CAST5 algorithms possibly don't fit inside the CPU cache very well (the Opteron chip has a larger L2 cache) or Serpent/CAST5 use operations that are more efficient on the Opteron chip. I don't know enough about the individual characteristics to make more educated guessed then that.
It's a pity that TrueCrypt isn't multi-threaded, or the dual-CPU Opteron system would've scored even higher on the TrueCrypt benchmark. I've run the benchmarks for a few different sizes (10MB / 50MB / 100MB / 500MB) and the numbers all tend to add up the same way (within a few percentage points) across the board.
Wolde you bothe eate your cake, and have your cake?
"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.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.