Posted
by
timothyon Thursday June 16, 2011 @04:50PM
from the guaranteed-wrongness dept.

An anonymous reader writes "I have been using Gentoo Linux for a long time now and have always been satisfied with one of its many disk encryption tools: cryptsetup (dm-crypt and LUKS). However, I recently gave FreeBSD a try and, although I concluded BSD is not for me, I was amazed at geli(8), FreeBSD's disk encryption tool. It happens this tool also provides what it calls an 'authentication mode.' Besides encrypting the disk sector-by-sector, it also stores checksums (sha256 in my case) in it on every write. On reads, if the checksum mismatchs, it propagates the error up, resulting in, say, a read() error. Thus I do not have to trust my disk (except of course for the boot partition) any longer: any data inconsistency will be detected before the data is used. Having searched for a long time without answers, I want to ask: is there something similar to this in Linux? Note: Using Btrfs is a valid solution, but is far from stable (got a few oopses during my tests)."

Yes, exactly. I've been using TrueCrypt for my important info (mostly pr0n), and have had no problems. It lets you choose between different encryption algorithms (blowfish, twofish, AES, and others I can't remember) and allows you to encrypt individual files, mount an encrypted virtual volume or encrypt your entire hard drive. And, as usual on/., its FOSS.

Nope, it offers full disk encryption, partition encryption, and file container, regardless of filesystem type within on Linux. My only problem with in on linux is the partition labels do not propagate thru mounting (eg/media/truecrypt1 instead of/media/MyDiskLabel)

Size: an empty EncFS filesystem consists of a couple dozen bytes and can grow to any size without needing to be reformatted. With a loopback encrypted filesystem, you allocate a filesystem ahead of time with the size you want. Depending on the filesystem, there may be ways of resizing it later, but that requires user intervention.

Automated Backups: An EncFS filesystem can be backed-up on a file-by-file basis. A backup program can detect which files have changed, even though it wonâ(TM)t be able to decipher the files. This way backups can be made without needing to mount the encrypted filesystem.

Layering / Separation of Trust: EncFS can be layered on top of other filesystems in order to add encryption to unencrypted filesystems. This also allows you to store data on filesystems you trust for storage but not for security. For example, EncFS could be used on top of a CD, or a remote NFS filesystem, Samba share, or perhaps even GMail storage using GMailFS.

Disadvantages

Meta-data: Meta-data remains visible to anyone with access to your encrypted files. This means that Encfs does not encrypt or otherwise hide the following information:

The number of files you have encrypted

The permissions on the files (readable, writable, executable)

The size of each file

The approximate size of each filename (to within 16 bytes using AES, or 8 bytes using Blowfish)

Rather than using some obscure thingo nobody's heard of, made by whats-his-name, I would speculate that the FreeBSD is safer, because they have people who understand crypto.

Philip Zimmer (of PGP fame) used to say that most people screw up in the implementation part.

Now, TrueCrypt you can trust, because it was used in a high-profile financial case in Brazil (it was mentioned here in Slashdot) and the Feds from Brazil and the USA (Brazilians asked for help) couldn't get the data out.

dm-crypt doesn't protect you against someone who is manipulating your hard drive while you're using it. It's intended to protect you after the hard drive is stolen. This is how most full disk encryption software works. It's not really "retarded".

What? What do you mean? You mean someone would be retarded enough to write an encryption method that doesn't use ECC or such internally?

Most encryption algorithms, whether implemented on a file or real-time on a disc, are not primarily concerned with ECC. Plenty use hashes, but not for the purpose of correcting errors caused by disk corruption. There are even less of the kind the author is looking for (real-time total disc encryption with ECC seamlessly integrated). It's not my speciality so I don't know of them

But if we're talking about sending and receiving data from long-term storage (rather than real time), that is easily attainable if

You have no clue about block-oriented storage encryption, obviously. There is no space for checksums and the task is done on a lower layer (the disk) and can be done on filesystem layer. Doing it on block layer in addition to the encryption breaks block alignment.

Probably the same reason why Linux is my main OS right now rather than FreeBSD, there's a few specific applications which I haven't been able to get running on FreeBSD, which work fine on Linux. Most applications can be made to work on FreeBSD if they work on Linux, but a few like Truecrypt won't.

Surely you've seen the "BSD doesn't support xyz" (where BSD clearly does support xyz) troll before? The other one we see a lot here is the "Netcraft confirms it... BSD is dying". That one never gets replies, though.

As far as I am concerned, you already said too much. Your post does not even remotely address the question asked. Please read the summary next time. As for the original poster: sorry, I don't know any such tool for Linux. ZFS has already been mentioned. Maybe you could compile Geli on Linux?

I Usually use LUKS with DM-Crypt [gentoo-wiki.com], but there are other tools more user-friendly that come with gnome. Last day I discovered a gnome applet that manages crypted volumes written on the fly as you modify the mounted folder, that scale with the size of the content of the volume. (Dm-crypt has a defined volume size that you cannot outgrow, and the chiffered file used to mount the volume always has the maximum size i

The code is available, but under terms of a license so insane that neither the FSF nor the Open Source Initiative (who maintain the definition of 'open source': on their list of approved licenses) consider it free.

This is also one of the reasons RMS prefers free/libre software -- it avoids this whole "well it's open, but not really" ridiculousness when it comes to insane licensing.

Nobody said all you have to do is make a program's code readable for audits to magically happen.TrueCrypt development is done in a closed fashion, with extremely few (any?) patches from outside sources, and a lead team actively hostile towards critique.Furthermore, it is extremely difficult to build close-to-identical versions of TrueCrypt due to build system ridiculousness.That is more why no audits have taken place.

Gentoo recently postponed using GNOME3 [blogspot.com] because it seemed like a "work in progress". Meanwhile, Fedora has shipped it, Ubuntu is now on the even less mature Ubiquity, and CentOS can't even get a modern release shipped out the door at all. Gentoo is looking like a stable Linux aimed at old geezers nowadays.

The beauty of Gentoo is that you can mix and match...There is a gnome3 overlay if you want it.

I like being able to have control over the system, so i can mix and match package versions at will... With most binary distros its an all or nothing upgrade - if you want new gnome3, you also need to take new x11, new glibc, new gcc etc.

It would be nice to have a TPM based authentication system as an option. This way, a Linux server can grab a memory image, have the hash of that passed to the TPM, and if unchanged, the boot process continues.

Add a PIN to the process, and the TPM will start denying access after a certain amount of missed tries, so brute forcing a filesystem key isn't going to happen.

This way, someone pulling disks, or booting the server from other media will be unable to decrypt the machine.

That is you have a recovery password or keyfile saved off on a USB flash drive. Same procedure with BitLocker.

The TPM is an advantage, an option in addition to the usual typed in passphrase. I wish other operating systems would take advantage of it, and not just Windows, because it brings with it some good security functionality.

You will probably get your wish, as there are people working on a secure boot using UEFI (modern replacement for BIOS) and the sort of cryptographic integrity validation you are talking about: https://lwn.net/Articles/447381/ [lwn.net] (subscription required, but free from 23 Jun 2011)

This can be used for good (if you own your own keys, you can compile and install your own kernel etc) or bad (if the hardware vendor or OS vendor owns the keys, you have no way to install anything else, i.e. you have a Tivoized system).

Linux users growing frustrated at the increasingly superior feature set of FreeBSD can take heart that FreeBSD is also open source, and runs all of your favorite software. The adjustment necessary is roughly that of moving from one Linux distribution to another.

Why not PGP (free for non-commercial use) or Gnu Privacy Guard (GPG, free). Both use the OpenPGP method and are interoperable with each other. While neither is open source, the source code for both are supposed to be available to anyone who wants to check the integrity of either application (e.g., lack of back doors).

This [wisc.edu] looks like a project to address adding checksums in the md(4) Multiple Device layer (not ideally named, because MD is perfectly usable on a single drive). Because MD is a layer under the filesystem, any filesystem is supported. They only support RAID4C (checksumming RAID4) and RAID5C (checksumming RAID5), though they show how to implement it on a single volume, albeit with a large performance penalty.

There is an excellent paper which analyzes the integrity issue you are trying to address.

The checksums need storage space. So you either have to reduce usable block size or use extra sectors. Both options mean you lose the 1:1 block mapping that both dm-crypt and LUKS (the latter with an offset) provide. This can cause all sorts of problems, unless the file-system layer is also optimized for it and therefore dm-crypt and LUKS delegate any such checking in addition to what the disks themselves already do to the file-system layer.

Not if you store the sum in another block. Look at how ZFS does it, very sweet because data stays data and the metadata contains the checksum. I could copy and paste the details here, but you could find those by yourself.

You should never trust your disk. The amount of unrecognized single sector failures on modern disks is so big, that with a >90% probability, at any given moment, a stripe/raid with four 2TB disks will contain at least one of them. All professional grade storage systems have disc scrubbi

Unfortunately ZFS support in Linux is userland only due to licensing issues. It may not have encryption yet either - however you could run TrueCrypt on top of a ZFS volume (like an LVM logical volume), bypassing the ZFS filesystem part.

Actually there are naive in kernel ZFS modules. There was a bunch of work done by the Lawrence Livermore National Laboratory to do a clean port. Currently the vdev layer is totally solid. Their using that as back end block storage for a lustre filesystem. However the guy who did the port has also released the posix layer as well.So, I can't speak to the licensing issues, but there is native ZFS support. Granted it's got a ways to go to be completely stable (from the posix layer level) but the vdev stuf

I was aware of this, but mountable filesystems are still only in a release candidate so it's some way from being usable. Also you do need to compile it yourself due to legal issues if it's distributed with Linux: http://zfsonlinux.org/faq.html#WhatAboutTheLicensingIssue [zfsonlinux.org]

Ports do not need to be compiled as root. But you do need to set WRKDIRPREFIX to somewhere the user can write. Ports will be build in this directory. By default the port system will use a subdirectory in the port itself, which indeed can't be written to by a normal user. It's all pretty well documented in the ports(7) manpage.
As for the second, nothing I can do about that. ARM is still a Tier2 supported architecture:(