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
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.
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.
Democracy: Crowdsourcing a country near you
TrueCrypt.
Nuff said.
http://www.truecrypt.org/
I think therefore I am... a Linux geek.
Absolutely. Just take an extra hard drive with the pad on it whenever you need to access your data...
It's better to vote for what you want and not get it than to vote for what you don't want and get it.
- E. Debs
*insert TrueCrypt license debate here*
Oh go on, i'll start it off.
There are some who would argue the license is dangerous.
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)
from 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
to 45 2F 6E 40 3C DF 10 71 4E 41 DF AA 25 7D 31 3F
Volume encryption?
Why is it needed? Unless you have a requirement that dictates this, there are more ways for volume encryption to fail.
I am surprised no one has mentioned encfs. You could run it in userspace over whatever precious checksumming system your heart desired.
http://www.arg0.net/encfs
Advantages of pass-thru system vs an encrypted block device
Disadvantages
"Flyin' in just a sweet place,
Never been known to fail..."
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.
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)
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?
Not TrueCrypt.
Nuff said.
also : https://tails.boum.org/support/truecrypt/index.en.html
I'll never say this enough : Don't trust Truecrypt when you have a shitload of similar/better tools that you can actually trust on linux.
I mean just look at this
Segmentation Fault in "Life, Universe and Everything" at line 42. Don't Panic.
... and I just finished compiling Firefox so I could submit this story to Slashdot!
*crickets* .. gee, tough crowd.
End of lesson. You may press the button.
<@insomni> it only takes three commands to install Gentoo /dev/hda && mkfs.xfs /dev/hda1 && mount /dev/hda1 /mnt/gentoo/ && chroot /mnt/gentoo/ && env-update && . /etc/profile && emerge sync && cd /usr/portage && scripts/bootsrap.sh && emerge system && emerge vim && vi /etc/fstab && emerge gentoo-dev-sources && cd /usr/src/linux && make menuconfig && make install modules_install && emerge gnome mozilla-firefox openoffice && emerge grub && cp /boot/grub/grub.conf.sample /boot/grub/grub.conf && vi /boot/grub/grub.conf && grub && init 6
<@insomnia> cfdisk
<@insomnia> that's the first one
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.
Gentoo recently postponed using GNOME3 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.
How is it that you didn't get TrueCrypt working? The current version is in the ports collection and works fine for me: http://www.freebsd.org/cgi/url.cgi?ports/security/truecrypt/pkg-descr
Yes but some people are too busy to read the summary! Have a heart.
Why's that?
Honest question, I've not heard the argument.
For pr0n you should definitely use blowfish, along with analfish
Not open source. Do keep up.
Have you read the license? Not GPL, Apache etc. Not really open source, although the source is available.
http://fedoraproject.org/wiki/ForbiddenItems#TrueCrypt
Hmmm, I believe you just bit a very common troll, how does it taste?
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.
Your comment is informative, however.
This tagline was transcoded to result in at least one smirk. If you experience failure to smirk, please consult your Gen
The link says that Fedora says the license is dangerous, but doesn't go into it at all.
Here is a more detailed explanation on the dangers from debian-legal, though it's 5 years old so I can't say whether or not it's even still relevant...
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...
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.
My personal favorite gentoo quote:
<@insomni> it only takes three commands to install Gentoo
<@insomnia> cfdisk /dev/hda && mkfs.xfs /dev/hda1 && mount /dev/hda1 /mnt/gentoo/ && chroot /mnt/gentoo/ && env-update && . /etc/profile && emerge sync && cd /usr/portage && scripts/bootsrap.sh && emerge system && emerge vim && vi /etc/fstab && emerge gentoo-dev-sources && cd /usr/src/linux && make menuconfig && make install modules_install && emerge gnome mozilla-firefox openoffice && emerge grub && cp /boot/grub/grub.conf.sample /boot/grub/grub.conf && vi /boot/grub/grub.conf && grub && init 6
<@insomnia> that's the first one
Ehh.... not to rain on the joke, but there's nothing in partition /dev/hda1 after mkfsing it. Why so quick to chroot into it? It's missing the stage3 download!
Unity, not ubiquity. And I really hope it does not become such...
"People don't want to learn linux" hasn't been a valid excuse since '03.
Not open source.
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.
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.
What I find ironic is that Google has not included this with Android, as it is the perfect tool for securing data on SD cards.
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).
Which is at least an improvement over the old process... (although emerge'ing firefox that early is a bit of overkill and makes the whole thing fake).
Wolde you bothe eate your cake, and have your cake?
Or Linux desktops still just look like the metric ass-load of crap they've all been since Enlightenment.
+++OK ATH
U-fucked-Up is the next Linux desktop project, I hear.
I love Linux. I hate Linux desktops.
+++OK ATH
They're all waiting for a broken Firefox emerge bug to be fixed.
+++OK ATH
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.
truecrypt well the consern it may have backdoors but never confermed.
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.
The definition of open source is maintained here: http://www.opensource.org/osd.html
It does not meet the requirements, therefore it is not technically open source.
Sorry, that was "all charges were dropped"
Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts
Sorry, Then my post should read: "Yes". :)
I think therefore I am... a Linux geek.
Sorry, please excuse my ignorance - (that's expressed honestly, not sarcastically) - I wasn't aware the OP was interested in only GPL? (Or am I missing something ... in which case I apologise profusely!)
I think therefore I am... a Linux geek.
Only GPL / only OSS / only RMS whatever. Sorry, not suggesting GPL is the "only" open source!
I think therefore I am... a Linux geek.
You've been modded down - I think that's a shame. You've made a discussion point - and been penalised for it.
What such tools would you suggest? Your last two linked articles don't work for me - could you summarise their content?
I suggested TrueCrypt because the NHS in the UK use it quite a bit (so I'm informed), for a free product (and one which I believe the source code is available for) it does the job quite nicely IMHO.
I think therefore I am... a Linux geek.
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.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
May I ask what made you conclude FreeBSD wasn't for you?
sorry the correct link was : http://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software
I Usually use LUKS with DM-Crypt, 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 it can reach --If I want a 15gB crypted volume, I get a 15gB file, no matter how empty the volume is.)
I know avoiding TrueCrypt sounds like tinfoil hat paranoia, but if you need te encrypt your data in the first place, maybe this is healthy paranoia.
Segmentation Fault in "Life, Universe and Everything" at line 42. Don't Panic.
my important info (mostly pr0n)
I think your definition of the words important and info must differ radically from mine.
To have a right to do a thing is not at all the same as to be right in doing it
Also didn't mount/bind the proc or dev file systems.
And what the hell @ installing _gnome_ before grub!
Last I checked TC didn't do file or block checksumming the way the posed question is looking for...
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
... and how does this let you detect or correct corruption?
Jesus people, at least read the whole question.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
The question posed is asking about disk integrity specifically. TrueCrypt does not do this.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Or maybe the quality of his pr0n differs radically from yours.
From Google's own invasive searchbots.
"Flyin' in just a sweet place,
Never been known to fail..."
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.
Spread your free software FUD elsewhere, that last bit is a fun little straw man...
tiffany is good
Thanks for reminding us that many things can be misrepresented if taken without regard to their context.