Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×

Encrypt Filesystems with EncFS and Loop-AES 63

Posted by ScuttleMonkey from the no-peeking dept.
Linux.com (Slashdot sister site) has a quick look a file encryption using EncFS and Loop-AES as examples before briefly examining other options. From the article: "you can find a number of options for filesystem encryption in Linux exist, depending on your needs. The most important thing when choosing which one to use is to be clear about your needs. Will the size of the files you need to encrypt grow or stay static? Do you need to encrypt certain files or entire partitions? What level of security do you need? Answers to these questions will help determine the most appropriate program to use."
This discussion has been archived. No new comments can be posted.

Encrypt Filesystems with EncFS and Loop-AES More

Encrypt Filesystems with EncFS and Loop-AES

Comments Filter:

  • Hmmm... (Score:1, Redundant)

    by Saeed al-Sahaf ( 665390 )
    What level of security do you need? Answers to these questions will help determine the most appropriate program to use...

    I see....

  • For good, easy, root encryption (Score:3, Interesting)

    by GenKreton ( 884088 ) on Monday March 20, 2006 @01:45PM (#14958125) Journal
    I use LUKS (Linux Unified Key Setup) on several of my machines. It is an extension onto cryptsetup and uses dm-cryp instead of loopaes. It is fairly easy to setup and allows for multiple users with different phrases if needed as well as tokens. It has treated me much better than loop aes had in the past.

    http://luks.endorphin.org/ [endorphin.org]

  • eCryptfs (Score:5, Informative)

    by omnirealm ( 244599 ) on Monday March 20, 2006 @01:51PM (#14958174) Homepage
    Don't forget this new competitor: eCryptfs, mostly written and supported by IBM, and fully GPL:

    http://ecryptfs.sf.net/ [sf.net]

    It's all in the kernel, which means that shares memory mapping work (unlike userspace filesystems), and it keeps metadata on a per-file basis, which is *really* nice for things like incremental backup utilities.
  • I threw together the following quick script to allow you to mount and unmount the EncFS encrypted filesystem easily:

    I think that pretty much summarizes the state of encryption on Linux. Yes, it can be done if you hack around with it, and has been so for a long time. Let me know when LUKS (Linux Unified Key Setup)/dm-crypt or any other of these tools can actually make a simple out-of-the-box GUI which is usable. To dick around on the command line and writing scripts to do that went out of fashion about the s

    • Re:Going nowhere slowly (Score:3, Informative)

      by Trelane ( 16124 )
      Let me know when LUKS (Linux Unified Key Setup)/dm-crypt or any other of these tools can actually make a simple out-of-the-box GUI which is usable.
      Sir/Ma'am? It's time [fubar.dk].
    • Let me know when [...] any [...] of these tools can actually make a simple out-of-the-box GUI which is usable.

      You have a GUI on your server? I don't. If it needs a GUI it would sound pretty UNusable for me.

      Of course a GUI could make it easier for casual encrypting on my desktop, but I have nothing worth encrypting on my desktop...

      • You have a GUI on your server? I don't. If it needs a GUI it would sound pretty UNusable for me.

        Some of us lazy bums do X over SSH to the server, at least the one I have at home. At work I end up using MSTSC a lot, no *nix there. Sure, I *can* try to do obscure stuff over SSH but it is usually faster (person time, not machine time) to use a GUI for those odd changes I do only once in a while, and setting up encryption certainly qualifies. At least with some of the more important data, I like to keep it both

  • Encfs (Score:3, Interesting)

    by toad3k ( 882007 ) on Monday March 20, 2006 @01:58PM (#14958229)
    Encfs is great, if you are x86. I made the mistake of unmasking it on gentoo amd64 and it flipped out and I ended up sorting through 300+ files in my l+f directory from my corrupted partition. But for x86 it is very convenient, I highly recommend.
    • I use encfs every day on my ~amd64 Gentoo system with absolutely no problems whatsoever. And secondly, how on earth did you corrupt a partition using encfs? Encfs is a layer on top of an existing filesystem. Methinks you may have tried using it a little... strangely.
      • Here's what I did. encfs -i 10 dir dir

        After 10 minutes, it auto unmounted itself, and then all my terminals responded with input/output errors. Of course, I can't reboot normally if I can't run any commands, so I had to cut the power. And when I had to cut the power with reiserfs that is where the corruption came from.

        This happened several times, but I didn't realize it was encfs causing it because it would happen 10 minutes after I stopped using my crypt directory.

        Anyways, about the 4th time it happened
  • I had a parition (approx 80 GB of data) encrypted via loop-AES in kernel 2.4. After the upgrade to kernel 2.6, I found I was unable to mount the partition correctly, unless I specified a depricated option when building the crypto loop tools.

    After doing so, I mounted the parition and everything proceeded normally...

    That is until a few months later when I upgraded my system again. Suddenly my parition was unreadable, and the previous option did not work in cryptoloop anymore. I posted for weeks on boards and

    • Re:Why I'll never use kernel level encryption agai (Score:5, Informative)

      by sholden ( 12227 ) on Monday March 20, 2006 @02:47PM (#14958634) Homepage
      Why bother waiting so long:

      1. boot into the old kernel/backout the upgrade.
      2. Mount encrypted filesystem and copy data elsewhere
      3. Create encrypted filesystem such that you don't get deprecated warnings.
      4. Copy the data back.

      I really can't understand continuing with something marked deprecated anyway - certainly not doing an upgrade while doing so. What do you think deprecated means? I'd be doing steps 2-4 as soon as the deprecated option was needed.
      • 2. Mount encrypted filesystem and copy data elsewhere

        See the problem there?

        • 2. Mount encrypted filesystem and copy data elsewhere
          See the problem there?

          Only because you snipped out his first step, which was to boot with the old kernel. I presume that something prevented you from doing so.

          • No, it's the "copy data elsewhere" that perhaps he's having the problem with. What if it's a laptop, which is common type of system to run an encrypted filesystem on? Perhaps he doesn't have any other machines, and it's pretty tricky to hook up a second drive to a laptop.
            I mean, I have no problem with it - boot with rescue CD/roll back to working kernel ver, copy drive to another drive, upgrade kernel, start new encryption system, copy data back from second drive. Yes, it's fairly simple. But if you don't
        • No.

          Backing out the upgrade shouldn't be difficult. At the very worst you install whatever version it was on a UCB pen drive and boot from it... (or CD-R or HDD or whatever you have available). The old rescue disk might even be good enough...

          But as I said deprecated means what it says, doing an upgrade when you are relying on something marked deprecated is pretty foolish - unless you checked the release notes to make sure they say it hasn't been removed of course.
      • It's easy to say this when it isn't you with the problem.

        You will just have to trust me when I say that I tried every single method at my disposal, every combination I could figure out of kernel / cryptoloop, to try to decrypt this data. I even tried reverse-enginerring the source to the decryption modules myself to try to get some kind of a command-line thing going.

        All I can figure is I was using some weird odd combination of cryptoloop and kernel thay should not have worked, but did. Then I lost it all.

        As
        • If you have no where to copy the data then clearly you also have no backups in which case the data clearly isn't worth a lot to you anyway. When a disk I ordered the other day finally arrives I have the fun task of moving a bunch of data around in order to turn the drives into RAID-5 - I don't have enough disk elsewhere for all the meantime and the disk it's currently on is to be part of the RAID... So all the stuff I don't use/care about too much is just going to stay on the 40 or so DVDs it's also on whil

          • If you have no where to copy the data then clearly you also have no backups in which case the data clearly isn't worth a lot to you anyway

            Ever think that maybe I don't have a secure location to keep these backups?

            If you're backing up encrypted data in an unencrypted form, you'd better be moving it off site to some very secure location. In my case I can't really justify any kind of budget for this @ my house.

            If you're talking about backing up the *encrypted* data, then it's all moot since it would not ha

            • If you're talking about backing up the *encrypted* data, then it's all moot since it would not have helped me anyway.

              What sholden is saying is that if you have a backup (encrypted or not) then you have room to put the data while you upgrade. Why could you not have done:

              1. Revert upgrade of kernel
              2. Copy encrypted data to backup, unecrypting as you go (i.e. back it up unencrypted)
              3. Upgrade kernel
              4. Trash old encrypted partition and replace with whatever you want to use now
              5. Restore backup, encrypting as you go
            • Well you could use a different encryption system for backups. In fact you're likely to unless you have some fancy filesystem which lets you track changes or if you are doing non-incremental backups all the time. Personally I use duplicity for encrypted backups (and would do so from an encrypted file system too - you really want to be able to diff the unencrypted data and then encrypt the backups seperately).

    • In stead of giving up on it, why didn't you just downgrade, decrypt, and upgrade again?
      • Or you could try my personal favorite, once mounted (and files no longer appear encrypted) then encrypt them on a file level with a daily/weekly job to backup. Personally I favor tape, 40-120GB backups encrypted with gpg, but you can use whatever you find cheapest/handy. No, if you have a serious crash, doing this doesn't keep it from sucking, it just keeps the suckiness to minimum.

        That way your backups are mostly secure even if your physical security is second rate or gets beaten, but you still get the s

    • Don't use a relatively "proprietary" crypto then. By proprietary, I mean "highly dependent on the running kernel and system". Linux kernel encryption is tough as it's changing regularly. I've avoided it.

      Instead I use Truecrypt which gives kernel level encryption but is far more platform independent, and hence by extension needs to be more stable.

      Works via a kernel module, but also the same encrypted "partition" (actually a file or partition) can be read and written to in Linux or Windows. Excellent for dual

  • Compatible with MacOS X FileVault? (Score:3, Insightful)

    by tji ( 74570 ) on Monday March 20, 2006 @02:24PM (#14958438)
    MacOS includes this functionality, in what sounds like a very similar manner. It can create a disk file, which is AES encrypted, and you can mount like any other disk. They also have the option of encrypting your whole home directory, but I've heard of people having problems with that..

    Which, if any, encrypted Linux filesystems are compatible with MacOS's filevault?
  • Encryption on servers makes sense when they can be physically accesses or seized.
    In my opinion, the number of servers physically seized is too low to bother about FS encryption. Infact when in use in a network server, all those files get somehow unencrypted to be sent over the network.
    And, AFAIK, almost all the intrusions, data thefts and the likes happen without accessing the actual file blocks on the disks.
    So, where are the FS encyption technologies supposed to be expoited?
    I see one area: mobile comput
  • The problem is to have one solution that Works For Me(TM), and Is Fast and Stable...
    Only LoopAES is in mainstream kernel right now and most people don't like partition meddling at all.
    I dream about one-click in a Konqueror menu "Encrypt this folder".

Slashdot Top Deals

"The four building blocks of the universe are fire, water, gravel and vinyl." -- Dave Barry

Close