Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
Encryption Data Storage Linux

Ask Slashdot: Tools For Linux Disk Encryption and Integrity? 123

Posted by timothy 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)."
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Tools For Linux Disk Encryption and Integrity? More

Ask Slashdot: Tools For Linux Disk Encryption and Integrity?

Comments Filter:

  • Yep (Score:5, Informative)

    by Anonymous Coward on Thursday June 16, 2011 @04:56PM (#36467992)

    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?

    • Re: (Score:1)

      by Anonymous Coward

      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

      • Actually I was thinking of Hamming-encoding post-encryption such that damage to one part didn't destroy the whole block...

    • Re: (Score:3)

      by gweihir ( 88907 )

      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.

  • TrueCrypt.
    Nuff said.
    http://www.truecrypt.org/ [truecrypt.org]

    • Re: (Score:3)

      by Chryana ( 708485 )

      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?

    • Re: (Score:3, Informative)

      by koolfy ( 1213316 )
      Not TrueCrypt. [wikipedia.org]
      Nuff said.

      also : https://tails.boum.org/support/truecrypt/index.en.html [boum.org]
      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 [slashdot.org]
      • 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.

        • Re: (Score:3)

          by koolfy ( 1213316 )
          sorry the correct link was : http://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software [wikipedia.org]

          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

    • Re: (Score:1)

      by Threni ( 635302 )

      Not open source. Do keep up.

      • 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!)
    • truecrypt well the consern it may have backdoors but never confermed.

    • The question posed is asking about disk integrity specifically. TrueCrypt does not do this.

  • I have been using Gentoo Linux for a long time now

    No takers?

    • Re:Just trolling (Score:5, Funny)

      by Verteiron ( 224042 ) on Thursday June 16, 2011 @05:47PM (#36468538) Homepage

      ... and I just finished compiling Firefox so I could submit this story to Slashdot!

      *crickets* .. gee, tough crowd.

    • Re:Just trolling (Score:5, Funny)

      by Wingman 5 ( 551897 ) on Thursday June 16, 2011 @06:15PM (#36468826)
      My personal favorite gentoo quote [bash.org]:

      <@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

      • Re: (Score:1)

        by Anonymous Coward

        My personal favorite gentoo quote [bash.org]:

        <@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!

        • Re: (Score:2)

          by Anrego ( 830717 ) *

          Also didn't mount/bind the proc or dev file systems.

          And what the hell @ installing _gnome_ before grub!

      • 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).

    • Re: (Score:2)

      by NateTech ( 50881 )

      They're all waiting for a broken Firefox emerge bug to be fixed.

  • TPM, please? (Score:2, Interesting)

    by mlts ( 1038732 ) *

    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 functiona

    • Re: (Score:1)

      by df5ea ( 227427 ) *

      Yeah, using the TPM would be great. Using a pin instead of a passphrase at most startups would be much less cumbersome.

      Obviously you would still need a backup passphrase when you change your motherboard or exhaust the maximum numer of pin tries.

    • Re: (Score:3)

      by Cato ( 8296 )

      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).

  • 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.

  • 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 [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.

    I wish this

  • That's how I interpret the question. Soon, by this fall, most likely.

  • 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 [wikipedia.org] http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/filesystems-zfs.html [freebsd.org]

  • 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

    • 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

      • Re: (Score:2)

        by gweihir ( 88907 )

        What ZFS does is perfectly fine. But dm-crypt and LUKS is a block-level crypto mapper, there this is about the worst thing you could do.

  • ZFS encryption (Score:3)

    by Cato ( 8296 ) on Friday June 17, 2011 @01:44AM (#36471504)

    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 [blogspot.com]. 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 [hardforum.com]

    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
  • May I ask what made you conclude FreeBSD wasn't for you?

Slashdot Top Deals

"Those who will be able to conquer software will be able to conquer the world." -- Tadahiro Sekimoto, president, NEC Corp.

Close