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."
I'll take the hardware encryption on my thinkpad anyday....
Software encryption is fine, but there needs to be better and more widespread hardware encryption (NOT DRM) facilties that can be taken advantage of in a cross-platform manner..
Obliterate advertising!
Apparantly, from the UK tomshardware.com redirects to tomshardware.co.uk which doesn't have the article.
Thats just annoying as hell.
liqbase
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 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 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.
Quidquid latine dictum sit, altum videtur
Encryption won't protect you from hackers if you have the drives mounted 24/7.
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.
There are no atheists when recovering from tape backup.
Which Linux (not BSD) distro is the most locked down secure from initial install? Regardless of other ease of use, or performance. Debian origin (for apt-get) preferred.
Since performance seems the biggest tradeoff, which "crypto coprocessors" (PCI DSP/FPGA/ASIC/etc) have Linux OSS drivers?
--
make install -not war
I found some interesting discussions about linux data security. Good read!
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."
If you have the 400 page ad loaded version as much as I do.
_ linux-creating_a_cryptobook/print.html
http://www.tomshardware.com/2006/08/18/locking_up
I was reading that Tom's article this morning around 8am EST. Oh well!
Every time you write a block to disk, it goes through a cryptographic checksum. Every time you send a TCP packet it goes through a checksum. The amount of CPU needed to do these checksums is not much different from the amount of CPU needed to do full encryption. We routinely use compression, which takes more CPU. If someone out there is thinking, "I would love to encrypt but I'm worried about performance", he's probably using a Mac Plus or a PC Jr or something. That isn't reality. Modern CPUs pipeline all these operations and do them so fast it will make no noticeable difference in anything.
Well mostly, the "issues" are more complicated then one might think:
Encryption is classified as a munition under the Internation Traffic in Arms Regulations (ITAR)
source: http://lrs.ed.uiuc.edu/wp/privacy/encrypt.html
As a desktop user, using hardware encryption will make no noticeable for anything. Even for servers, modern CPUs are so fast. A typical website spins its CPU on things like databases and bad PHP code. The SSL encryption hardly matters.
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.
I have two DirecTV Tivo units and I will keep them until they die unless the replacement offered has a way to transfer my saved videos to it. All I ask for is a one time transfer. Through a software download update, they enable a USB to Ethernet or USB to USB way to connect my old machines to the new one and transfer my videos. They can even be deleted from the old machine as they are copied.
Of course having some decent HD content would also help.
Letting me get files from the DCR to my computer would be nice, but is not realistic.
Quite useless article when the most advanced and mature Free Software disk encryption system for GNU/Linux is not mentioned.
Try this insteadi nux-creating_a_cryptobook_uk/
http://tomshardware.co.uk/2006/08/16/locking_up_l
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
Errr... What?
I welcome the Virtex4 module for Opteron. Hope it's user-programmable. Such an FPGA can even contain seperately loadable modules. Perhaps someday Linux and Windows will be able to manage it automatically based on the applications that are currently running.
The worst thing about TrueCrypt, it seems, is the license. They claim that it's "free open-source", but this is not obvious when reading the license (which is its own funky license, not a standard one).
Debian, for example, has not packaged it due to the license.
It's a shame that everybody thinks they need their own special license for their program. Bleh. You are not special. You are not a unique snowflake. If you want to write an open-source program so people can use it, then don't make a custom license that prevents it from going into common Linux distros, dorks.
I am disappointed to see that Justin Korelc and Ed Tittel entirely missed eCryptfs, which is already in the -mm tree of the Linux kernel.
An unjust law is no law at all. - St. Augustine
For a minute there I thought that someone had "locked up" the linux kernel in the "Windows lock up" style. Whew...
Don't think that a small group of dedicated individuals can't change the world. It's the only thing that ever has.
A problem with Linux encrypted partitions is that there are several formats, and no migration path.
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...
A way to find out if there's hidden data is to fill up the volume with files, no? "Hm, this says the disk is full, but by my count there's 180MB missing somewhere."