Slashdot Mirror

Surely you jest? Getting amanda to encrypt your backups. Is just a matter of reading some howto files on amanda's website. And, just peeking over at bacula's website, I can see that they have a similar sort of setup. I don't use bacula, but I'm sure it is a matter of following the directions just like with amanda. It is not clear how anyone can consider encrypting backup tapes as a difficult process. For that matter, with TrueCrypt, OpenSSL, GnuPG, FreeBSD's geli, and linux's dm-crypt encryption in general has become easy and accessible. Add to that the hardware acceleration built into most new systems or just pure computational power of modern processors and organizations are remiss for not using encryption at nearly every turn. If you don't, you should lose your job.

Why wouldn't you just do your encryption at the block device level using dm-crypt? Then it doesn't matter what filesystem you're using.

Someone further up said that btrfs can now do volume management. Are you proposing to do the block device level encryption below btrfs (using a second level of btrfs or a different volume manager to create the logical devices)? Or above btrfs (if btrfs even supports logical volumes within itself, like ZFS does) and then use btrfs or another filesystem within that container?

You can begin to see the problems with non-integrated volume management, encryption, compression, and deduplication.

Why wouldn't you just do your encryption at the block device level using dm-crypt? Then it doesn't matter what filesystem you're using.

Where's Jasper when you need him?

http://www.saout.de/assets/jasper2.gif

I use it on my swap and /home partitions on my laptop, but when doing heavy writing to the disk, the whole machine locks up for 1 or 2 seconds at a time - no mouse movement, no sound, no cursor - then it resumes. These freezes occur every 10 seconds or so as data gets flushed out to the disk.

From my point of few I do not see any reason why the hard drive of a cooperate laptop computer should not be encrypted as soon as the mobile computer contains sensitive data (and it usually does). In my opinion it is just irresponsible to carry any mobile device (laptop, USB stick, etc.) out of the company if the data is not secured there, and the series of data leaks known to us all proves this. It might be a bit more inconvenient, it might cause some overhead in computing, but in my opinion this measures needs to be done.

I have a Linux laptop (IBM T30, 2GHz Pentium 4) and I have not a full disc encryption, but /tmp, /var, /usr/local, /home, /root and the swap area are encrypted (256bit AES). With the 2.6 kernel series it has become easy to set up encrypted partitions with dm-crypt and recently with my new acquired external harddrive I started to use the Linux Unified Key Setup (LUKS) which makes it even more convenient to have encrypted drives (now I can give away my external harddrive to a friend and he can use it without knowing my key, the system allows up to 8 keys and each of them can be revoked easily). I have never noticed any lack in performance and nowadays computers are even faster than my Pentium 4.

Further, if it comes to data loss due to a lost key, then may I ask, where is the backup? I have a backup of my system, for sure encrypted (Dar is here for me a great help). In a cooperate setting backups should be standard as well (harddrive failures happen as happen that keys get forgotten). So loosing a key should not be a problem. One does not need to encrypt the backup either, after all the encryption should only prevent data from being read when the laptop gets stolen and into wrong hands. If the backup is secure in the cooperation than there is nothing (big) to fear if it is not encrypted.

So what point really justifies to take the risk of data leak in a cooperate setting??

These developments will bring file security to many non-technical users, but for the nerds out there there have already been practical solutions for some time.

I've been keeping the hard disk of my Linux encrypted with twofish for over three years now (see the description of this encryption method in Bruce Schneier's magisterial Applied Cryptography ). Swap is encrypted with a random key generated on each boot-up. At first I used the old cryptoloop method, but as soon as the kernel support was there I switched to the crypto device-mapper target. I never noticed any performance penalties: this is a very efficient solution.

Loop-AES is not the current recommended way of doing this on GNU/Linux.

For the current method, check out device-mapper, dm-crypt and cryptsetup.

For more information, check out: http://www.saout.de/misc/dm-crypt/

And for a guided howto install Debian on a USB stick with everything but /boot encrypted, check out: http://www.debian-administration.org/articles/179

It's interesting to see xxxBSD user/developer comparing "just written" software for BSD with ancient versions of Linux counterparts and (surprisingly) finding xxxBSD version to be better. My point being: dm-crypt.

If you are interested in Linux 2.6 encrypted partition, use dm-crypt together with cryptsetup tool. It's much safer than AES loop and:

• it allows to use encryption algorithms in CBC mode;
• uses published linux kernel crypto API, which means that you can use any cipher known by kernel;
• because of the above, if kernel has hardware support for some crypto algo, dm-crypt uses it automagically: I have a very low power VIA Epia MicroITX board (soon to be replaced by even lower power Nano ITX board by Epia) serving as my home fileserver. The processor, VIA Nehemiah is disgustingly slow at it's 800MHz, but it has VIA Padlock crypt engine doing AES in hardware -- access speed on encrypted AES256-CBC partition is indistinguishable from the speed on the same non-encrypted disk, and a lot higher than on my Pentium M 1.6GHz notebook with Blowfish (i.e. the fastest-yet-quite-safe) dm-crypt partition.
• because it uses Crypto API, you can use any new safer or faster algo, whether it's done in software or hardware, as soon as there is crypto api driver for it (crypto using GPU anyone? ;)
• with existing cryptsetup tool you can create encrypted swap partition with random key taken from /dev/random; and since some platforms (e.g. VIA Epia, but also chipsets from Intel, AMD and others) have true hardware random generators with Linux drivers, I wish a lot of luck to someone trying to recover passwords from my swap device ;)
• while existing key generation method is not as kosher as described PKCS#5 PBKDF2 or multifactor solutions, cryptsetup is just a userspace tool controlling kernel space diskmapper virtual disk engine; you can write your own tool and initialize your dm-crypt partitions any way you want;

OK, I'm tired, go read the links and you'll be much wiser and better informed than after reading TFA ;)

Robert

I propose an easy solution... encrypt the whole drive with AES256 or stronger, dm-crypt, stegfs or similar mechanisms, or better yet.. a combination of all of the above.

Its not their data, they have no business poking around in it, "different file structure" or not. Keep them out with strong encryption. You have nothing to hide, and they have no business looking.

About encrypted filesystems on Linux:

• From memory, the MS system has a mechanism for key recovery and/or an admin back-door. This makes sense in an office situation (e.g someone leaves or is fired) but it still leaves me wondering about other backdoors. It doesn't sound like paranoid-tinfoil-hat-crowd level encryption to me.
• dm-crypt was introduced in kernel 2.6.4. This uses the new device-mapper API to encrypt a file or device. From what I've read, it's a much cleaner implementation than cryptoloop.

Unfortunately there is no in-filesystem encryption, yet. It's still a little clunky to encrypt a whole filesystem at a time. It'd be much more efficient to be able to mark a directory (and all its children) as being encrypted with a certain key. I believe some people are working on this, so we might see it eventually.

About virtual terminals: I gather that most distros now use gdm, kdm, or even good old xdm to provide an all-graphical login. None of this clunky startx stuff. Much more prettier looking as well :)

About user switching: I think KDE recently (last year?) added a "switch user" feature. I'm a Gnome user, so I'm not really sure. I know I've seen it recently, but I can't find it in the Gnome foot menu here. So it's probably in KDE.

• Loop-back encryption is kinda clunky. dm-crypt looks to be a cleaner way to do encrypted devices. And pam_mount can mount encrypted home directories on login.
• As for doing encryption in the filsystem, several people are at working at it.
• Your notion that OpenSSH only creates a tunnel while the "console" is open, is little more than FUD. Oh no! The console!. That's the whole point. SSH is largely interactive by its very nature.
• It's quite easy to setup OpenSSL in inetd mode for SSL'd services.
• Encrypted executables? Are you joking? WTF would that achieve? If someone has physical access to your machine, you're screwed anyway. And if someone has broken into your machine remotely then your executables are probably the last thing to worry about. On Unix/Linux systems you need root access to write to system executables. If an intruder has root access, they can do anything and don't need to modify your executable to screw around. This is a straw-man argument.
• Linux is very good as a VPN router. Not only do we have IPsec/IPV6 from the KAME project, there's also the (abandoned) FreeS/WAN project and the spin-off Openswan. But don't forget OpenVPN (available for quite a few platforms, not just Unix/Linux). If you're really desperate, you can always combine SSH and PPP to make a VPN.
• Tokens? You have heard of Kerberos haven't you?
  BTW, here's a good LDAPv3+SASL+KerberosV HowTo

My god you are a troll. Oh, and as others have pointed out, encryption does not instantly make something secure.