Locking Up Linux, Creating a Cryptobook 68
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."
Hardware encryption (Score:3, Insightful)
No, software. (Score:5, Insightful)
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.
Re: (Score:2)
Furthermore, THG's article claims to have tested large file sizes but their graphs dont show it. In order for a filesystem to be correctly benchmarked, the test file size must be at least twice the size of RAM. If it isn't then the test is only testing RAM speed, algorithm speed, and Linux's page cache system. According
Re: (Score:2, Informative)
The speeds reported are not believeable for a Pentium III M 1.2 GhZ even for just encryption.
Re: (Score:2)
FPGA ftw (Score:1)
Hardware encryption is stupid, except on servers (Score:1, Insightful)
This isn't the 90s anymore. 2ghz CPUs are standard now. Dual CPUs are standard. I would be surprised if hardware encryptors have any edge over general-purpose CPUs these days.
Re: (Score:2)
Speed is also still an issue. I would like to see Tom's test repeated with a VIA C3 as we
Re: (Score:2, Informative)
The only remaining reason to keep hardware encryption around is to protect your private keys. Even in this way hardware can be problematic. If you have important private keys locked away in hardware, you need to have som
Re: (Score:1)
Re: (Score:1)
Not available in UK (Score:2, Informative)
Thats just annoying as hell.
Re: (Score:1)
Re: (Score:3, Informative)
That sounds like outgoing connections to port 8080/8090 are blocked for you. Are you behind a restrictive corporate firewall?
For ./er from UK (Score:3, Informative)
http://tomshardware.co.uk/2006/08/16/locking_up_l
Multi-user laptops (Score:5, Informative)
Now, this might not be a common thing in the US. But here in India, a lot of companies have team laptops which we pass around (on-call duty for server pages, for instances).
And somebody from Delhi, did something up which works for exactly that. qryptix [sourceforge.net] encrypts your home dir and mounts using your passphrase when you login, built as a pam.d module.
Except for the fact that I wanted a truecrypt [truecrypt.org] built into it, so that I can have a hidden volume even after I pass-phrase in to the first volume, this works well enough for most purposes.
Re: (Score:1, Informative)
encryption vs security (Score:4, Insightful)
It's only good for protection against stolen data, eg. usb drives or cds/dvds.
Or, if you keep your entire computer at unsecre location, and are afraid that someone will steal the entire machine(root crypto).
But remember, encrypted filesystems are vulnerable to cryptanalysis since they contain specific information at specific blocks even if encrypted(ext3 header etc..)
Encryption won't give you perfect cover, but if you really have something valuable to protect, it's decent way to go.
Performance WILL be an issue, don't be blinded with those luks graphs, real world performance will be much closer to the cryptfs/encfs performance numbers, but it's fast enough. Just encrypt what you have to. No need to encrypt entire system if you can get away just by encrypting home dir.
Re: (Score:3, Interesting)
Re: (Score:2)
but encrypting swap is as(or even more) important than encrypting data.
I agree with you fully with that point.
Re:encryption vs security (Score:5, Informative)
Re:encryption vs security (Score:5, Informative)
Re: (Score:1, Interesting)
If the encyrption is done properly, then naturally whole partition is encrypted (including ext3 header etc..).
"Performance WILL be an issue, don't be blinded with those luks graphs"
No it won't, unless you will run a file server or something similar. Do you think that in the average use it will matter wherever your HDD's read speed is 20MB/s inst
Re: (Score:1, Informative)
See http://www.cs.auckland.ac.nz/~pgut001/pubs/linux_
Re: (Score:1, Interesting)
Re: (Score:3, Informative)
Part of the minimum design criteria for a crypto algorithm is to resist "known plaintext" attacks, such as knowing the location of magic numbers, headers, and so on.
Re: (Score:2)
Encryption isn't supposed to protect you from crackers and script kiddies. It's supposed to protect you from media theft and traffic interception/interference. Why expect a tool to provide some miraculous protection it was never designed to?
Crackers can't get to the machine unless it's connected. If your data is important enough to encrypt, WTF are you doing leaving the box exposed to the 'net? The only thing a secure box should expose is the services used to access the secured data.
Security First (Score:2)
Since performance seems the biggest tradeoff, which "crypto coprocessors" (PCI DSP/FPGA/ASIC/etc) have Linux OSS drivers?
Re: (Score:3, Informative)
Some interesting discussions (Score:1, Troll)
TrueCrypt? (Score:5, Interesting)
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...
Re: (Score:1)
Then you are faced with proving that there isn't any encrypted real data amongst the random free space...
Re: (Score:2)
Which is, for all intents and purposes, impossible--putting the burden of proof on your adversaries. In court the suspicion or possibility of there being something more is circumstancial evidence at best.
-Grym
Re: (Score:1)
You're talking US, UK, Canada. Parent is talking Syria, Lebanon, Iran.
Re: (Score:3, Informative)
Re: (Score:2)
I'll leave the US as an exercise for another.
Re: (Score:3, Insightful)
The design of truecrypt is that it isn't possible to tell whether there is a hidden volume or not - it just looks like unused space.
Re: (Score:1)
Re: (Score:3, Informative)
So, yes it does look like "used" space. But it also looks like "empty" space by the same virtue. If you just put your regular checkbook in a truecrypt volume and put something else in a hidden volume it would be plausible to say that the checkbook is the only thing in there.
Re: (Score:2)
If you mount a truecrypt volume that contains a hidden volume and you don't specify the hidden volume passphrase then it just mounts the non-hidden volume. The non-hidden volume behaves as if it occupies the full space of the file/device it is contained in - if you write lots of data it will keep on writing right over the hidden volume, destroying it (without any way to tell this is happening). The only way to safely write to the outer volume is to mount it with the passwords to both
Printable view of TFA (Score:3, Informative)
http://www.tomshardware.com/2006/08/18/locking_up
Re: (Score:3, Funny)
Gee, I should have submitted this.... (Score:1, Offtopic)
What is up with performance concerns and crypto? (Score:1, Insightful)
My experience (Score:5, Informative)
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.
eCryptfs (Score:4, Informative)
Linux can lock up? (Score:2)
Formats and upgrades (Score:3, Interesting)
As usual, when new and better solutions are developed, the Linux developer scene does not really care about backward compatability. The new method is sooo good that the old one should be left in the dust and its adopters must backup and restore.
Developers who suggest backup and restore must be unaware of the current market situation w.r.t. backup solutions and their capacity vs that of IDE disks...
Recently I decided to move two disks from my main system, encrypted under SuSE 9.2, to another box that I want to dedicate to background storage.
I remembered that I had read about some issue in 9.3, but I believed that it had been long solved so I installed SUSE 10.0 on this new box.
There was NO WAY I could get the disks mounted. I tried all the tricks found in several articles on Internet, but I kept getting errors.
The SuSE knowledge base stated that everything would be fine when I just upgraded the OS, but I don't believe that because I tried the solutions equivalent to what would happen when upgrading. I don't want to risk it.
Finally, the only solution was to install 9.2 on the new box, and the disks worked OK. Then, I have bought more disks (as was the plan) and copied the data from encrypted to unencrypted disks. Next step will be to install 10.0 again, but I am not so sure if I will encrypt the disks again as the 10.0 system is (I believe) not LUKS so probably at 11.0 I will again face the same problem because the "all new and better LUKS" is now the supported system.
I will not even think about what would happen when I would want to change the distribution from SuSE to RedHat or Ubuntu or whatever.
Chances must be about zero that I can still access the data.
There is not even a tool that would in-place decrypt (or encrypt, for that matter) the data on a partition. Even when one wants to take the risk that it interrupts halfway and destroys everything. So you always need a source and destination device with enough space.
Please keep this in mind before you encrypt your terabyte volumes...