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."
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
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
Try this insteadi nux-creating_a_cryptobook_uk/
http://tomshardware.co.uk/2006/08/16/locking_up_l
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)
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
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):
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).
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
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
Bran muffins and whiskey.
>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.
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.
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.
v pn.txt about how hobbyist "security" software can really suck.
See http://www.cs.auckland.ac.nz/~pgut001/pubs/linux_
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.