Slashdot Mirror
Locking Up Linux, Creating a Cryptobook
Tom's Hardware has a nice overview about some of the latest ways to secure your data looking specifically at open source solutions that wont lock down your credit card. Since many people presented performance issues for why they don't implement encryption there was also special attention given to how well your system will perform after implementation of encryption. From the article: "At least where LUKS is concerned, performance is hardly an issue - one must expect to pay some penalty for additional encryption facilities that handle unencrypted data transparently. All of these solutions are simple to set up and use on a daily basis, but LUKS is portable across Windows and Linux platforms."
A pity they don't mention TrueCrypt.
Besides encrypting your data, TrueCrypt can also create hidden volumes:
"The principle is that a TrueCrypt volume is created within another TrueCrypt volume (within the free space on the volume). Even when the outer volume is mounted, it is impossible to prove whether there is a hidden volume within it or not, because free space on any TrueCrypt volume is always filled with random data when the volume is created* and no part of the (dismounted) hidden volume can be distinguished from random data. Note that TrueCrypt does not modify the file system (information about free space, etc.) within the outer volume in any way."
So even if you reveal your password, the hidden volume stays safe. Not a bad feature, considering it is a crime in many countries to refuse to give your encryption key to the authorities...
It is not so much that I have confidence in scientists being right, but that I have so much in nonscientists being wrong
I'm not sure I agree with this.
Software encryption is really superior to hardware in many ways. Basically the only way it's usually not superior is in terms of speed, and this is why you see hardware encryption implemented.
However, as general-purpose computers have gotten faster and faster, so that there's more surplus capacity for things like encryption and decryption on the fly, I see the need for hardware encryption becoming less and less.
There's just no reason to restrict yourself to a hardware-based system that's hard to upgrade and fix, when you can use a software system that can be kept in tune with the state of the art and is a lot easier to trust. Even if I'm a relatively interested and intelligent person, there's no way I can 'open up' a hardware encryption module and see what's going on inside. With software encryption, I can look at the source code (and provided I'm using a trusted compiler and toolchain) know what it's doing.
Furthermore, software encryption leads to more diversity in implementations. When you use hardware systems, the only way they're affordable is if there is an economy of scale. You don't make just a handful (or even a few thousand) hardware modules, you want to make tens or hundreds of thousands of them. That means it's automatically going to be a big target. With software, everyone can use something that fits their needs more completely, and the exposure of the system as a result of a single exploit is reduced.
Hardware encryption was fine when computers were too slow to encrypt data that was being written to disk on-the-fly. But now they are, and this means that you can use regular equipment, and use whatever cryptographic implementation you want, and upgrade it as often as is required, with minimal additional expense. In fact, if I was going to build a "hardware" encryption device today, I'd probably just design it around a general-purpose system-on-a-chip so that it would be easily reprogrammable. I can't imagine that for anything but the most specialized, very speed-intensive tasks, that a custom-made hardware solution is really advantageous.
Not that I'm saying that all cryptographic hardware is bad; there is definitely room for specialized components without making entire hardware encryptors: dedicated hardware random number generators, for instance, seem like they'll definitely have a place for the foreseeable future.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
I've been running my desktop on an encrypted root partition using LUKS (on Gentoo via dm-crypt) for over 6 months now.
I was afraid that heavy IO access might cause high CPU usage or that some FS might not play all that well with the encryption.
So far, I've had no problems. Even copying from one encrypted partition to another encrypted partition causes no noticeable lag due to encryption and normal usage of my disk, even with heavy uses such as DBs or backups seems to take place just like before.
I've been using LUKS with xfs (and reiserfs to a lesser extent). I have a P4 3.2Ghz, don't remember the disk specs.
Being able to have several passphrases is a good thing (you can even change them later on) and the assurance that a weak passphrase will not cause the key being easily guessed via crypto-analysis is another plus.
The downside is that booting from an encrypted partition can be a little difficult to setup for a novice, but that has been improving and at least Gentoo now offers this on the current genkernel with little extra hassle.
If you want the whole package, you can even encrypt the swap partition with a randomly generated key at boot time.
What do you get from all this?
Suppose your computer has an hardware malfunction and you have to send to be repaired (warranty for instance). You can be sure no one will find the financial data you saved there, or some less flaterring photo (or something more embarrassing you didn't even remember). Using an encrypted partition to save sensitive data might be enough, but many programs end up saving temporary data in unexpected places so all that care might be useless in the end. If everything is encrypted that risk is gone with just a little bit of extra work (once).
Like someone wrote, this won't protect you from having you computer hacked while the partition is mounted and stealing data.
https://www.accountkiller.com/removal-requested
Mod parent up - if I do, I loose my own addition to the discussion. Most block ciphers are quite immune to known plain text attacks. This is at least true for DES and AES. And well implemented stream ciphers are as well (I specifically say "well implemented" because of the the flawed WEP implementation for WiFi).