Slashdot Mirror
Ask Slashdot: Tools For Linux Disk Encryption and Integrity?
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)."
You can use IMA (2.6.30 and later) and EVM (2.6.38 and later). :)
ZFS has checksumming on every block
Check out TrueCrypt, http://www.truecrypt.org/
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?
Support my political activism on Patreon.
Just use a one-time pad.
Since I've been using FreeBSD for a decade now and I like geli very much, it's not very interesting for me what Linux alternatives there are. But one thing is interesting... why did you decide that (Free)BSD is nothing for you?
Linux Disk Encryption Comparison
Nevermind that this has been covered many times before.
I saw that episode. Archie can't choose between Betty and Veronica.
"Flyin' in just a sweet place,
Never been known to fail..."
TrueCrypt.
Nuff said.
http://www.truecrypt.org/
I think therefore I am... a Linux geek.
I have been using Gentoo Linux for a long time now
No takers?
Flexible bare-metal recovery for Linux/UNIX
Please keep in mind the current 0.5.2 stable release does not yet support a mountable filesystem.
And considering that btrfs was not stable enough for the author, I don't think that is an option either.
Flexible bare-metal recovery for Linux/UNIX
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.
Essentially, BitLocker functionality (which admittedly is very good)
Makes it very hard to replace a motherboard when one dies. All the encrypted disks are useless.
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.
TPM enables treacherous computing. No thanks.
Yes but some people are too busy to read the summary! Have a heart.
BTRFS does check-summing on all data and has automatic data scrubbing. It can also do a RAID-1 of sorts with one hard drive, storing all data twice on the same disk. If it sees a checksum error, it will re-duplicate the good copy. Or you could use two hard drives using BTRFS RAID support.
I've been using the eCryptFS built into Ubuntu & touching /fsckcheck in either a recovery or single-user shell every time power gets cut but I'm sure you want something a bit more fancy...
Have a Look at :
http://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software
3 possible options:
Encrypt an SD card.
Encrypt a 7z archive.
Encrypt a virtual folder with EncFS.
Archives are better for backups that are not changing.
EncFS Virtual folders are good for daily use (loss of data happened to some people).
SD cards are good for monthly backups.
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.
In the past, this might have been an issue, but virtually every x86 server and server motherboard out there comes with a TPM present, but disabled and unowned.
Yes, it can be used for DRM, but since the functionality is there, might as well use it for good, and to ensure that a machine hasn't been tampered with, and that the MBR is intact.
Another use for it is a secure keystore for public/private keypairs. For example for code signing, you copy a public/private keypair into it (keeping a backup in a secure, offline place), and if someone compromised the box, they can sign stuff, but do not have access to the keypairs.
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).
If you liked FreeBSD, the kernel, but didn't like the userland, why don't you take the good of both worlds, and install Debian kfreebsd, which is Debian, but running the FreeBSD kernel?
This 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.
I wish this would get into linux kernel mainstream.
That's how I interpret the question. Soon, by this fall, most likely.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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 separate the encryption and error detection tasks. For error detection, and just as important, being able to fix those errors when they happen (two separate things) the term you're looking for is Forward Error Correction (FEC) software. If you're serious about backing up your data, and it still being around and undamaged in a few years, you should be serious about FEC. It amazes me how many enterprise-level companies frequently back up millions of files, but have no strategy for ECC.
Using vdmfec (my favorite FEC software. For linux), say you have a file that is 1gb that you'd back up with it (Large archive files are especially important to use forward error correction on, because plenty of them, if they get data corruption in the wrong place, get totally screwed up.) So, let's say with vdmfec you select the blocksize to be 5 kb, and then you select two positive whole number parameters, K and N. For every original K blocks, N blocks are written so that if up to N-K fail, you can still recover all original K blocks.
In plain english, if I set a K value of 10 and an N value of 30, then the first 50kb of the file would be transformed into 150kb. There could be quite a few bits accidentally flipped in that 100kb over time, but as long as any 10 of the 30 blocks did not suffer any damage, that set of blocks would be entirely fine. You can pass different K and N arguments according to your needs (reliability v. size) for a reasonably reliable disc over the short term, K=15 and N=20 would do just fine.
For encryption, use whatever you'd like, total disk encryption, folder encryption etc. One concern is that if you use any error detection or correction, it establishes a reliable data pattern which can be used to break the encryption. This concern can be solved by encrypting before applying error correction instead of after, or using encryption of sufficient bitstrength so that it will take another several decades for the hardware to be developed to crack it.
Stick with FreeBSD and use ZFS. It includes filesystem-level checksumming, deduplication (just rolled into STABLE) and encryption (still in CURRENT) http://en.wikipedia.org/wiki/ZFS http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/filesystems-zfs.html
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.
But the second thing is this: You have to basically trust your disk anyways. You can also trust your disk in most cases, as the rate for an unrecognized read error is basically low enough that these will not happen in practice, unless the disk is seriously damaged (e.g. defective buffer RAM). So unless you use extremely large amounts of storage (say, > 500 disks) and extremely high integrity needs, I would suggest you are barking up the wrong tree and want something here that you do not in fact need.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
ZFS has very good per-block checksumming and many other features, and now has encryption support, which should be in OpenIndiana (the non-Oracle fork of OpenSolaris): http://milek.blogspot.com/2010/10/zfs-encryption.html. ZFS is a combination of volume manager (like LVM), software RAID and filesystem. Here's a useful HOWTO on setup: http://hardforum.com/showthread.php?t=1573272
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.
U geli?
Just wanted to mention that...
May I ask what made you conclude FreeBSD wasn't for you?
It makes more sense to run ZFS ontop of an encryption solution (TrueCrypt, LUKS, whatever you like) to have the fun parts of ZFS available (filesystems, snapshots, compression, dedup).
tiffany hahaqhahahahahahahahhaahaaa
FreeBSD's geli does not provide authentication because it is vulnerable to replay attacks. Although it is written in the man page, I ignored it because "replay attack" was not clear enough for me. Thus, the only real solution is use a filesystem like Btrfs since it builds a tree of hashes. The stability of Btrfs given the disk is not trusted is questionable and its hash function is weak (crc32). However, I will go with it hoping the underlying block cipher strengthens the crc32.
Jeremiah Cornelius is talking to you http://slashdot.org/comments.pl?sid=2245866&cid=36480118
Thanks for reminding us that many things can be misrepresented if taken without regard to their context.
Why build something that not use checksums. It doesn't make sense. Eric Http://rotterdamescortservice.com, Rotterdam Escort