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."

Not available in UK

[LiquidCoooled]

Apparantly, from the UK tomshardware.com redirects to tomshardware.co.uk which doesn't have the article.

Thats just annoying as hell.

Multi-user laptops

[Gopal.V]

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:Multi-user laptops

[Anonymous Coward]

A similar project of note is pam-mount [sourceforge.net], a pam module to mount (usb|smbfs|losetup+crypt|LUKS|whatever) on login and umount upon logout. Too bad this is a performance-centric article, there are some very interesting things one can setup with (LUKS|device mapper|losetup). For instance encrypting your /tmp+swap with one-time keys from /dev/urandom.

Printable view of TFA

[pair-a-noyd]

If you have the 400 page ad loaded version as much as I do.

http://www.tomshardware.com/2006/08/18/locking_up_ linux-creating_a_cryptobook/print.html [tomshardware.com]

Re:encryption vs security

[Anonymous Coward]

But remember, encrypted filesystems are vulnerable to cryptanalysis since they contain specific information at specific blocks even if encrypted(ext3 header etc..)

That's bullshit. If your implementation is vulnerable to this, then it's flawed.

Re:Not available in UK

[Per Wigren]

Has ANYONE here ever been able to succesfully view a coral cached page? Either times out for me or just takes so long that I guve up (I.E. 20 minutes later the html is still loading.)

That sounds like outgoing connections to port 8080/8090 are blocked for you. Are you behind a restrictive corporate firewall?

For ./er from UK

[AtomicBomb]

Try this instead
http://tomshardware.co.uk/2006/08/16/locking_up_li nux-creating_a_cryptobook_uk/ [tomshardware.co.uk]

Re:TrueCrypt?

[rich_r]

No, it's a crime to not give up your encryption key in the uk. Furthermore, it's the only crime for which the burden of proof is on the accused. Don't have a link to hand, but I believe it's the RIP act of '99. (commentary here [reading.ac.uk])

My experience

[cvalente]

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.

Re:No, software.

[portmapper]

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 to THG, LUKS can sustain > 100MB/sec on a 20GB laptop drive from 2002. Hmmm, I think not.

The speeds reported are not believeable for a Pentium III M 1.2 GhZ even for just encryption. For comparisons, below is the output of "openssl speed" using a Opteron 170 (dual core, 2 GhZ):

timing function used: getrusage
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
md2 1319.99k 2852.42k 4012.43k 4463.32k 4616.59k
mdc2 0.00 0.00 0.00 0.00 0.00
md4 12368.68k 43225.00k 123294.14k 239186.25k 326060.22k
md5 10343.67k 34100.40k 89670.38k 154227.67k 192088.84k
hmac(md5) 12247.16k 38659.27k 98929.88k 161080.15k 197054.32k
sha1 10349.75k 32168.77k 77261.21k 118780.01k 141100.42k
rmd160 5952.92k 15180.22k 28828.97k 36378.64k 40787.12k
rc4 136573.04k 143986.99k 145413.62k 146386.75k 146586.59k
des cbc 34461.90k 35701.70k 37036.93k 37175.49k 36608.52k
des ede3 13751.49k 14061.98k 14140.86k 14095.64k 14166.87k
idea cbc 0.00 0.00 0.00 0.00 0.00
rc2 cbc 21347.66k 21906.79k 21789.39k 22140.53k 21636.99k
rc5-32/12 cbc 0.00 0.00 0.00 0.00 0.00
blowfish cbc 65679.12k 71584.56k 72852.48k 73303.87k 73445.24k
cast cbc 53265.79k 56068.99k 56726.04k 57409.73k 57494.63k
aes-128 cbc 86677.02k 90569.60k 92748.63k 92012.46k 93433.72k
aes-192 cbc 75476.78k 80489.02k 81191.59k 82528.12k 82633.50k
aes-256 cbc 67846.54k 71592.09k 73376.29k 73320.49k 73532.54k

Re:encryption vs security

[owlstead]

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).

eCryptfs

[omnirealm]

I am disappointed to see that Justin Korelc and Ed Tittel entirely missed eCryptfs [sourceforge.net], which is already in the -mm tree of the Linux kernel.

Re:Security First

[kneeless]

Debian Etch will have an option to use encryption by default and encrypt all partitions (except boot). This one article details how to encrypt all partitions except boot: http://www.debian-administration.org/articles/428 [debian-adm...ration.org]

Re:encryption vs security

[Beryllium Sphere(tm)]

>encrypted filesystems are vulnerable to cryptanalysis since they contain specific information at specific blocks even if encrypted(ext3 header etc..)

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:No, software.

[mophab]

In my experience, hardware encryption doesn't keep up with speed either. If you are using software encryption, it gets faster along with everything else as you upgrade to faster machines. Hardware encryption just does not keep pace with the increasing speed of general purpose processors.

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 some backup plan if the hardware fails, or is not fast enough to meet future demand. So even in this case, you are probably better off with general purpose hardware that will protect/destroy its contents if physically attacked. Of course you can keep the hardware with the private keys on a secure subnet as well.

Re:encryption vs security

[Anonymous Coward]

Apparently not. And the scary thing is, those are the kind of people who hack together yet another VPN or other crypto-software with massive flaws in them.

See http://www.cs.auckland.ac.nz/~pgut001/pubs/linux_v pn.txt [auckland.ac.nz] about how hobbyist "security" software can really suck.

Re:TrueCrypt?

[Rich0]

Truecrypt volumes are filled with random data when they are initialized, and appear random when files are created/deleted. There is nothing you can do to tell whether a volume was ever written to without knowing the key.

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.