Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Seeking Current Info on Linux Encrypted FS? 297

Posted by Cliff from the protecting-your-personal-data dept.
slick_rick asks: "I'm looking for info on encrypted file systems under Linux to help my employers company move away from Microsoft centric solutions. However the latest HOWTO is two years old, the latest kernel patch dates back to April (and 2.4.3) and even the Sourceforge project has nearly zero documentation and appears to be very dead. Are slashdotters using encrypted file systems? If so, what are your experiences?" We last talked about this topic, just over a year ago, in this article.
This discussion has been archived. No new comments can be posted.

Seeking Current Info on Linux Encrypted FS? More

Seeking Current Info on Linux Encrypted FS?

Comments Filter:
  • I tried to use win2k's efs, and it ruined me.

    Tell them that!

    • Re:win2k (Score:2, Informative)

      by TheCabal ( 215908 )
      I tried to use win2k's efs, and it ruined me.

      Tell them that!

      Ever heard of a File Recovery Agent? There's one set up by default on every Win2k system. And it gets better... you can add more!

  • FreeBSD & NFS (Score:5, Insightful)

    by stygian ( 222011 ) <curtis.jonesNO@SPAMgmail.com> on Thursday November 29, 2001 @10:47AM (#2630938) Homepage
    It's been a long time since I set it up under FreeBSD...but, as I recall, it had a very easy-to-setup system for creating an encrypted filesystem. I just 'cattach' it when I boot the machine...and I'm the only user than can look at the contents. It's really quite nifty. And I've never been able to find a good Linux equivalent.

    • Re:FreeBSD & NFS (Score:5, Informative)

      by stygian ( 222011 ) <curtis.jonesNO@SPAMgmail.com> on Thursday November 29, 2001 @10:51AM (#2630971) Homepage
      csfd - that's what it was. The Cryptographic File System.... The readme for the FreeBSD port is:

      This is CFS, Matt Blaze's Cryptographic File System. It provides transparent encryption and decryption of selected directory trees. It is implemented as a user-level NFS server and thus does not require any kernel modifications.

      ftp://research.att.com/dist/mab/cfs.ps

    • Re:FreeBSD & NFS (Score:3, Informative)

      by Marcus Brody ( 320463 )
      I've never been able to find a good Linux equivalent.

      Try SuSE. Because they are a European distro (ie no problems with US export controls), and also aimed at secure/server market (unlike mandrake), they have Very Good built in security measures. It is really very trivial to set up a crypto file system. You really should give it a go. See this [suse.com] for some breif details.
      Only problem is SuSE dont make iso's downloadable, so you might need to buy (gasp!) a copy. Money well worth spent though.

  • loop-AES (Score:4, Informative)

    by Sami ( 83769 ) on Thursday November 29, 2001 @10:48AM (#2630941)
    Have you tried the loop-AES patch [sourceforge.net]? It isn't exactly an encrypted FS, but you can create encrypted virtual drives with it.

  • Stuck in Windows? Bestcrypt works okay... (Score:4, Informative)

    by Bonker ( 243350 ) on Thursday November 29, 2001 @10:48AM (#2630948)
    It's a fairly decent encrypted filesystem implementation. I'm certain is has it downsides, but besides being non-free, I haven't found any others.

    BC allows you to create encrypted volumes up to the max size of your harddrive, and encrypts anything therein with your choice of encryption schemas. It also comes with a 'Wipe' command that will allow you to delete a file or clean a drive with a 7-stage delete process.

  • Reiser4 (Score:5, Informative)

    by jeffphil ( 461483 ) on Thursday November 29, 2001 @10:50AM (#2630963)
    If you can wait until September 2002, ReiserFS v4 will have an encryption plugin builtin. [namesys.com]

  • Encryption is fine. Decryption doesn't work (Score:3, Funny)

    by Karma 50 ( 538274 ) on Thursday November 29, 2001 @10:51AM (#2630970) Homepage
    ÖcéqêK8N& #9561;fö,á>c GîIk&#85 96;:á9fYé7$¼F~ ÿeCCLìM& #9616;ÿ4-
    /ñlöúi;`&#957 1;r÷\^"Ç SHNHÄN$RiDeb"&# 9492;3@É-'&#983 5;úïfM¼fz&#978 8;
    ÷¥ä=jN¥ká&#9567 ;êå0#0_R'&#955 3;lf'\@& #9524;te1q :Æ¥ôä&# 9580;Eüb#
    .¥c&#9688 ;Æ>ÿ"w&#9562 ;å+íÅ ï8XRO"# )Wÿ'fò^òY&#9571 ;Kñ2">[.0&#9 786;0Z
    ÿ!(VIi±(Av#;d}x övëëúóî|KÖ9&# 9792;9Jq]@2Oü-ö @[WcáÅU3 j

  • SuSE does this out of the box... (Score:5, Informative)

    by pwagland ( 472537 ) on Thursday November 29, 2001 @10:51AM (#2630972) Journal
    I am not sure about the other distributions, but as of SuSE 7.2, they do this out of the box. The support was improved in 7.3.

    Note that this filesystem based encryption, not user based. I.e. you must enter a password to mount the filesystem, but after that it acts as a normal filesystem (but slower due to the aforementioned encryption).

    The way that SuSE do it is to have an encrypted block device, so that you can throw anything you want on top of it. Typically this would be a filesytem ;-)

    From the SuSE webpage:

    * A highlight of SuSE Linux security technology: the so-called "crypto file system". Secret or sensitive data is encrypted on your own PC. This method is so safe that even if your notebook ist stolen, nobody, absolutely nobody (!) has even the slightest chance of decrypting your data. In addition, the crypto file system is so smart that the thief will not even notice that encrypted data exists.

  • XOR encryption is supported out of the box... (Score:4, Informative)

    by grytpype ( 53367 ) on Thursday November 29, 2001 @10:55AM (#2631003) Homepage
    ... take a look at "man losetup", which has a good example of setting up an XOR encrypted loopback filesystem. XOR is pretty crappy encryption however.
  • on SuSE crypto FS is an option during installation, so you might want to check this [sdb.suse.de] it is writen for suse but there is some usefull info in there for all distros.

  • Deniability (Score:5, Informative)

    by Tet ( 2721 ) <slashdot@nOsPam.astradyne.co.uk> on Thursday November 29, 2001 @10:56AM (#2631009) Homepage Journal
    Encrypted filesystems are useless without deniability. Rubberhose gives you that: http://www.rubberhose.org [rubberhose.org]
    • While rubberhose looks like an excellent piece of work, it's not true that encrypted file systems are useless without deniability. Encrypted file systems are often used commercially so that if the hardware is stolen commerical secrets are not made public. In such a situation it's unlikely that the user will be tortured to reveal the password.... (for example, I work at home, and all my source and email is on encrypted disks - my employers understand that I will give up the password at the slightest hint of danger, but still want encryption).

    • Maybe for you.... (Score:5, Interesting)

      by coyote-san ( 38515 ) on Thursday November 29, 2001 @11:07AM (#2631096)
      Maybe you need deniability, but out here in the real world a lot of people should be using encrypted file systems just to ensure that sensitive or confidential information is not exposed to others if the disk is stolen, the cleaning people are bored, etc.

      Personally, I don't want my doctor to have deniability about his records regarding me. Or my lawyer. Or my accountant. And most especially not my banker, financial adviser, etc.

      In fact, for these people deniability makes a solution look much less attractive. People get *really* nervous when their accountant or lawyer has strong deniability about what the advice they gave you, about where your money went, etc.
      • Now that Ashcroft has thrown out attorney client privledge it maybe very important for your attorney to have deniability. Since all phone conversations between attorney and client can be tapped you may desire that communications take place in an encrypted email format. You may then want your lawyer to encrypt his filesystem for when the fed come knocking down his door.

    • Re:Deniability (Score:4, Insightful)

      by Syberghost ( 10557 ) <syberghost@@@syberghost...com> on Thursday November 29, 2001 @12:06PM (#2631464)
      Rubberhose doesn't give you deniability.

      The presence of Rubberhose software and a huge segment of random noise on the disk is going to be enough to convince a court that you have a Rubberhose partition.

      The suggested "create 1GB of noise and then put two partitions in it, and just say you've got one" isn't going to work either. The court is gonna say "oh, you've got 1GB of noise according to our expert, but only a 300MB partition with nothing incriminating on it? Yeah, right, buddy; gimme the password for the other 700MB partition or you can rot in jail on contempt".

      Even a couple megs of "unused" space is going to be taken as a sign you've got a small partition hidden, if you've got Rubberhose software on the system to access it.

      Steganography only works when the carrier files have utility beyond that of the hypothetical encrypted information.
      • I forgot to add, which do you think a judge is more likely to believe:

        1) There's an encrypted partition, but I forgot the password.

        2) There's software for accessing steganized encrypted partitions, with documentation that recommends creating a large chunk of noise to hide it in, and there's a large chunk of noise, but there's no partition, I just keep random noise on my 2GB drive and only use this 1GB partition, the rest is just where I store the random noise, honest.
        • The judge is very likely to believe: I am not required to give this information by way of my fifth amendment rights. That implies you've got something to hide, and I assume the jury can take that into account, but they can't force you to give the key. All of this assuming, of course, that you are in the US and not the UK.

          This article [richmond.edu] comes to the conclusion:

          {72} Cryptography may provide a technical fix for Supreme Court decisions allowing the invasion of one's private papers. However, the effectiveness of that fix will depend on whether the Court holds that use immunity from the compulsory production of a cryptographic key extends to the incriminating documents decrypted with the key. Logic suggests that the Court should so hold.
          But that means nothing compared to actual precendence, of which I am not aware, 'cause I don't really keep up with this stuff. I assume it's protected, as the recent case against that mobster was borderline and it wasn't a question of whether the guy would be forced to give his password, but what to do once it had been aquired.

          • Re:Deniability (Score:3, Informative)

            by Syberghost ( 10557 )
            But that means nothing compared to actual precendence, of which I am not aware, 'cause I don't really keep up with this stuff. I assume it's protected, as the recent case against that mobster was borderline and it wasn't a question of whether the guy would be forced to give his password, but what to do once it had been aquired.

            There's a great analysis on the Rubberhose web site, talking about the legal precedents and arguments currently existing.

            The argument that Fifth Amendment protection doesn't extend to things you've already said, such as information on a hard drive already, is scary, even if you don't find it compelling. Courts don't always rule in accordance with a particular interpretation of the law, much less in accordance with logic.

        • Re:Deniability (Score:4, Funny)

          by friscolr ( 124774 ) on Thursday November 29, 2001 @01:39PM (#2632158) Homepage
          which do you think a judge is more likely to believe

          use OutGuess [outguess.org] and store your data across your porn jpegs! I've been collecting porn over the past 8 years for just this purpose!!!

          the judge is *most* likely to believe:
          "Your Honour, all those files are of naked men and women getting it on. i have 40+ gigs of it for variety!"

          like you said...
          Steganography only works when the carrier files have utility beyond that of the hypothetical encrypted information.

  • 50 ways to leave your lover (Score:4, Informative)

    by mAsterdam ( 103457 ) on Thursday November 29, 2001 @10:56AM (#2631012) Homepage
    ...and at least 10 ways to encrypt your data:
    http://koeln.ccc.de/~drt/crypto/linux-disk.html
    gives them.

  • cryptfs (Score:4, Informative)

    by sdxxx ( 471771 ) on Thursday November 29, 2001 @10:58AM (#2631023)
    There is a cryptographic file system you can get for SFS [fs.net]. If you go to the download page [fs.net], it's called cryptfs. Unfortunately, you have to install SFS first to compile cryptfs.

    Cryptfs is fully functional, though it was indented mostly as a proof of concept. The point is that such file systems are not hard to build, should someone want to maintain one. Here's an undergraduate programming assignment [nyu.edu] in which the students build a fully-functional cryptographic file system as an NFS loopback server.

    • It's easy to implement a crypto filesystem, but hard to do it *right*.

      Some quick examples:

      1) Is a standard cipher used? (easy, now that libraries are widely available)

      2) Is a standard cipher used *correctly*? (e.g., no ECB mode!)

      3) Does the same data in two blocks encrypt to the same ciphertext? If not, how are you randomizing them? What happens if you copy an encrypted FS from one media to another, e.g., via backups?

      4) How do you detect an incorrect encryption key?

      There's then the whole issue of key management, the truly hard part. How do you generate the key from the password? How do you support multiple users on the encrypted file system? (N.B., this is cryptospeek for "how do you prevent disgruntled employees from encrypting your data then walking away?" This usually means secondary and even tertiary keys automatically inserted by the system.) How do you handle system reboots?

      Finally there's the mundane. Top of that list - how do you handle backups? Can you back up the encrypted data? Can you deny backups of the unencrypted data?
  • ftp://ftp.kernel.org/pub/linux/kernel/people/hvr

    Try that :)

  • It's Really Pretty Trivial (Score:5, Insightful)

    by Lethyos ( 408045 ) on Thursday November 29, 2001 @11:01AM (#2631051) Journal
    The kernel patch you refer to is not outdated. There just is no reason to release new versions. Here's how you patch your kernel with the international patch.

    One level up from your Linux source tree (typically /usr/src), do...

    zcat ~/patch-int-2.4.3.1.gz | patch -p0 -E

    You'll notice a chunk fails. The ONLY problem here is patching the root Makefile. Look at the file /usr/src/linux/Makefile.rej. It shows you what lines failed. You can easily fix this by adding (under the DRIVERS line)

    CRYPTO = crypto/crypto.o

    And changing the line

    SUBDIRS = kernel drivers mm fs net ipc lib

    to...

    SUBDIRS = kernel drivers mm fs net ipc lib crypto

    Now your kernel should be properly patched. Make it mrproper, then configure as needed. Add the proper cyphers (I'm sure you can figure this out). Typically, serpent and blowfish are the best choices. Also, build them as modules so you can harvest a little extra entropy. :) Also, make sure you build the loopback device as a module, and then add crypto support. I assume you know how to load modules

    Now for the easy part. Once you have the kernel modules built and loaded, make sure you have the latest mount tools (including losetup). Pick the device file you want to use as an encrypted file system. For this example, I'm going to use hda3 with 256 bit serpent encryption for shits & giggles.

    losetup --keybits 256 --encryption serpent /dev/loop0 /dev/hda3

    It will prompt you for a pass phrase. Use a PHRASE and REMEMBER this. You cannot change the passphrase of an encrypted fs after you set it. Get it right. Next, format the device /dev/loop0 with your favorite file system (I prefer ReierFS because I've had trouble with ext2 fscking of encrypted file systems -- data loss most notably whenever I mistyped my passphrase). Do something like

    mkreiserfs /dev/loop0

    Now, destroy the loopback device...

    losetup -d /dev/loop0

    And add the following line to your /etc/fstab

    /dev/hda3 /mountpoint reiserfs defaults,loop,auto,encryption=serpent 0 0

    Now, every time you boot or mount that file system, it will ask you for the key length and the pass phrase. And there you go. Encrypted file system. Yea.

    You can see how trivially easy that was and if you had put about half an hour's thought into it, you could have realized that the "outdated" howto hasn't been updated because the process is pretty much unchanged and you would not have wasted our time with yet another linux newbie Ask /. question. But that's just my opinion.
    • You should really take a look at CFS. With a little patching it will compile under the various RH distros. Go here for patches: CFS patches [finerty.net]
    • You can see how trivially easy that was and if you had put about half an hour's thought into it

      Right.

      That kind of attitude will really encourage people in general to use Linux and encryption on a daily basis...

    • Re:It's Really Pretty Trivial (Score:3, Interesting)

      by Anonymous Coward
      You were doing a stellar job there until the uncalled for jabs at the end of that post. Maybe there are other slashdot readers out there that are interested in having an encrypted file system?

      Maybe having an encrypted file system could be part of the install process for upcoming Linux distributions - an easy to use system for encryption in the partitioning stage of the install. Couple that with a runtime tool that can create encrypted partitions after the install, and you immediately have another big plus point over Windows, especially for people in government who have a habit of leaving laptops with top secret material on in taxi cabs.

      In other news, the UK government is going to buy 500,000 copies of Windows XP. As a taxpayer, I disagree with this use of my tax money, and with the close relationship that the current government has with Microsoft. I feel that the best solution for the taxpayers is not being researched in the name of PR and photo opportunities for government ministers. And why does the government need to upgrade their computer system to Windows XP? What is wrong with 2000 - a proven OS now, not a just released one...

      • SuSE does this now, and at a presentation I saw on it recently by a SuSE guy he specifically mentioned it and demonstrated it.

        I imagine the other distros won't be far behind.

        Ewan
    • Although I will not be verifying your implementation, your post is well written and seems very informative. Why did you go and blow it at the end??

      I constantly have to defend myself against being called part of a cult that is "drinking the Kool-Aid" and this type of attitude does not help. I am proud to be a geek/nerd, but the moment anyone thinks of me as arrogant or haughty, I feel bad.

    • Apologies (Score:3, Insightful)

      by Lethyos ( 408045 )
      Sorry to everyone who was offended by my last comment in this post. I did in fact mean to help, but I just though that the original submitter of this Ask /. question could have done a little more work figuring this out. Hell, even I managed to get my file systems encrypted with that outdated HOWTO.

      Nonetheless, I'm sorry for spoiling something informative with some elitist babble. It's just a knee-jerk reaction from time to time.
    • The kernel patch you refer to is not outdated. There just is no reason to release new versions. Here's how you patch your kernel with the international patch.

      Actually, I remember reading (mailing list? cryptoapi doc? newsgroup?) that the patch-int should NOT be used, because the implementation of several cyphers (twofish comes to mind) is broken.

      As I already wrote in another post, I didn't do extensive testing to compare patch-int and cryptoapi, but I *did* have lost data with patch-int: some files got garbled beyond repair (to quantify, I'd say less than 1% of them). I was using twofish.

      Now I'm using cryptoapi, and I didn't have any trouble (at least not yet).

      Another point: you may have troubles with losetup/mount, depending on the distribution you use. In that case, download util-linux from the kernel site, apply the patches and recompile. I keep two separate copies (called losetup-crypto and (u)mount-crypto) of the utilities.

      I don't think I agree with the the suggestion about reiserfs. ReiserFS has no trouble with fsck simply because it doesn't do fsck... I'd suggest use whatever you want but disable auto-checking or, even better, modify the startup scripts to make sure that the passphrase is good (just try to mount the fs) before attempting a fsck.
      • As I already wrote in another post, I didn't do extensive testing to compare patch-int and cryptoapi, but I *did* have lost data with patch-int: some files got garbled beyond repair (to quantify, I'd say less than 1% of them). I was using twofish.

        I had this problem once or twice, but using either serpent or blowfish. It happened after typing a bad passphrase... and e2fsck kicked in and complained about fs errors. Of course, I've gone a little crazy with my set up. I have two hard disks, each encrypted with a different algorithm, that are then interleaved using RAID0. I love it. :) But it's trouble prone.

        Now I'm using cryptoapi, and I didn't have any trouble (at least not yet).

        Got any links or should I just look in standard locations? (Kernel archives, freshmeat?)

        Another point: you may have troubles with losetup/mount, depending on the distribution you use. In that case, download util-linux from the kernel site, apply the patches and recompile. I keep two separate copies (called losetup-crypto and (u)mount-crypto) of the utilities.

        That's one reason I mentioned having the latest utilities. Older versions don't support crypto stuff (obviously). But there's really nothing wrong with making hte latest util-linux package your primary. Why do you keep separate binaries?

        I don't think I agree with the the suggestion about reiserfs. ReiserFS has no trouble with fsck simply because it doesn't do fsck... I'd suggest use whatever you want but disable auto-checking or, even better, modify the startup scripts to make sure that the passphrase is good (just try to mount the fs) before attempting a fsck.

        Well, I suggested Reiser because in light of things not being set up properly, I think it's a little more careful before it goes and tries to replay a journal on a corrupted fs. That may actually be a positive fault here, as giving up early protects your data. In general though, I prefer a journaled fs so I'm boasting some advocacy here. :)
        • Got any links or should I just look in standard locations? (Kernel archives, freshmeat?)

          It's the one at cryptoapi.sourceforge.net. I didn't mention a link since it was in the story submission.

  • Try BestCrypt (Score:4, Informative)

    by Wee ( 17189 ) on Thursday November 29, 2001 @11:02AM (#2631054)
    I know it's not really an encrypted filesystem, per se, but BestCrypt [jetico.com] might be enough for you. It's a bit like NAI's PGPDisk. Essentially, you mount an encrypted file and then access it like any other disk (it has a mount point, etc). The nice part (for me) is that they have a Win32 version as well, so using BestCrypt and Samba means that I can have my wife's securely store her Quicken stuff on my fileserver (which is the only machine that gets a backup). The only "bad" thing about BestCrypt is installation. You have to make real sure your kernel sources are in good shape. I had a few issues installing it because I had a few different kernel sources laying around (not good, I know, I know...). Anyway, it's not that hard to install, but not a userland type thing either.

    Like I said, it's not a filesystem, but it might get you by. I personally don't care if /etc is encrypted or not. But I might care if /home was encrypted. It's easy enough to mount a BestCrypt container file at /home, so that might be enough.

    -B

  • ...and is seems to work ok. There's a problem with the compilation, you need to add -DEXPORT_SYMBOLS in the api/ subdir makefile for it to compile correctly.


    Apart from that I never had any problem with it, but I admit that I never did much testing.

  • CFS (Score:2, Interesting)

    by Anonymous Coward
    I use CFS, which is a daemon the uses NFS to encrypt file and filenames. The files are stored encrypted on an ordinary filesystem.


    It works well. I'm no security expert buy I can see a couple of problems with it. Firstly it uses triple-DES. Probably secure enough, but not so fast. There are certainly more suitable ciphers out there.


    The key comes from a pass phrase. cfs forces you to have a pass-phrase with at least enough bits to fill the DES keys, but obviously unless you like memorizing long strings of random charcters there will be far less entropy than required in the key.


    Secondly meta-data is not encrypted. So, although Eve can't tell what is in a particular file, she can see the directory structure (but not filenames) and when a file was created/modified/accesses.


    Apart from these criticisms it seems quite good. Users can create/attach/detach encrypted filesystems without special priveledges. You can specify a timeout on a file store so it is dettached after a certain period.

  • Ehrmm.. Cliff, why do you think this specific feature might help moving people away from MS-centric thinking? I'ld say most people who know about cryptography know about non-MS systems, the others might not be terribly interested. Please explain.

  • SUSE has it (Score:2, Redundant)

    by HighTeckRedNeck ( 538597 )
    The install for SUSE version 7.2 professional had it built into the install. Select expert partitioning and it was a check box selection in the mount-point, file system type dialog box. You could edit the boot sequence to remove the prompt to mount the file system and then mount it only when you wanted it mounted. Once mounted it was visible in unencrypted form but you could un-mount anytime. Reading and writing is done via a loop back that decrypts /encrypts during read/write. It is visible as a standard file system once mounted to all programs by all users. SUSE 7.3 has this to say http://www.suse.com/us/products/suse_linux/i386/se curity.html Watch the space in security, comment dialog box is too small to fit url without it injecting a space.

  • RubberHose (Score:2, Redundant)

    by Acy James Stapp ( 1005 )

    The Rubberhose encrypted filesystem might be more suitable for individuals.

    Read about it at www.rubberhose.org [rubberhose.org]. It's primary feature is deniability, (from their web page)

    Rubberhose is a computer program which both transparently encrypts data on a storage device, such as a hard drive, and allows you to hide that encrypted data. Unlike conventional disk encryption systems, Rubberhose is the first successful, freely available, practical program of deniable cryptography in the world. It was released in an earlier form in 1997, but has undergone significant changes since that time. The design goal has been to make Rubberhose the most efficient conventional disk encryption system, while also offering the new feature of information hiding.

    Rubberhose is a type of deniable cryptography package. Deniable cryptography gives a person not wanting to disclose the plaintext data corresponding to their encrypted material the ability to show that there is more than one interpretation of the encrypted data. What deniable crypto means in the Rubberhose context is this: if someone grabs your Rubberhose-encrypted hard drive, he or she will know there is encrypted material on it, but not how much -- thus allowing you to hide the existence of some of your data.

    • StegFS (Linux only) is another steganographic filesystem. It's licensed under the GNU GPL, unlike Rubberhose.

      http://www.mcdonald.org.uk/StegFS/ [mcdonald.org.uk]

      • stegfs scared me away with this line from the paper describing the implementation [cam.ac.uk]

        Multiple copies of both inodes and data blocks are stored on disk, so that if one or more copies are destroyed then
        hopefully others will remain intact.
        (emphasis mine)

        Hopefully! this is my data, not my lottery ticket! i need a bit more reliability than a "hopefully".

        i haven't used StegFS, though, so perhaps this hopefully works out to be more theoretical than it sounds, but i'd still like a guarantee that my data will be there unless i choose to delete it. Yeah i know that's tough given the whole deniability thing, but still, i'd like that guarantee.

        • Read further, and you probably won't be as worried.

          Only when the filesystem is mounted at a lower access level (or as a plain ext2 filesystem) is there a danger of overwriting blocks of encrypted data.

          If you're always using the filesystem with the highest access level, you don't have anything to worry about. It's only when there's a lot of data being written at a lower level that you have to worry.

          If that's the case, like it's a partition that contains home directories for other users, you're already asking for trouble. This should be a filesystem that only you use on a regular basis.

  • CryptoAPI (Score:5, Informative)

    by Agent_Leprechaun ( 452587 ) on Thursday November 29, 2001 @11:18AM (#2631163)
    Do a search on google for CryptoAPI. That's the new encrypted filesystem interface for linux. The pathes for 2.4.3 are old. I have an encrypted file system working with 2.4.16 patched with GRSecurity. You no longer need to patch the kernel with CryptoAPI, it just creates kernel modules that you install. It's pretty easy to do.

  • I've used it the last 2 years (Score:5, Insightful)

    by lessthan0 ( 176618 ) on Thursday November 29, 2001 @11:25AM (#2631199)

    For the past two years, I've been using it in several distributions, manually applying the kernel patches and compiling the necessary programs (utils). But with SuSE (>7.2), kernel encryption is built in which has saved me a load of time compiling it into the kernel.

    SuSE uses twofish as the encryption algorithm which is good enough for me. I would prefer to use serpent, but not enough to recompile everything. Both twofish and serpent were finalists in the U.S. Federal AES competition, both losing to rijndeal. Of course, W2K/XP use weak 56-bit DES in their EFS and have administrator back doors, so it barely qualifies as encryption.

    If you want fast, reliable, and easy to use enrypted file systems, choose SuSE!

    • Wrong. EFS does not use 56-bit DES you idiot.

      Microsoft is using 128-bit DESX encryption for EFS. What is DESX? It's a strengthened version of DES created by RSA Laboratories.

      http://www.rsa.com/rsalabs/faq/3-2-7.html

      As far as the back doors are concerned. If it's your own machine you have nothing to worry about because only you would know the backdoor. However for a corporation the administrative back door is regarded as a must-have feature in case an employee is fired, dies, leaves the company, whatever.

      Why are Linux users so bloody ignorant?

  • encrypted root + warning about crypto in linux 2.4 (Score:5, Insightful)

    by patbernier ( 9544 ) on Thursday November 29, 2001 @11:30AM (#2631228) Homepage

    For the truly paranoid, or as used to be my case, for laptops that travel a lot and hence are very prone to theft, the cool thing to do is to encrypt your (almost) entire disk, with your root filesystem on an encrypted loopback device, and no swap at all (because swap can't efficiently be encrypted, and RAM is so cheap anyway nowadays). Of course you still need to keep a small unencrypted boot partition to host your kernel, and an initrd image. The initial ramdisk must have a script that will setup the loop device -- prompting you for your passphrase -- before proceeding with system boot.

    For additional protection, you might be tempted to keep this boot partition on a business-card size CD-R, thus making sure that nobody can insert code to steal your passphrase, but if they have access to your system for long enough, they could install a hardware keylogger and you're screwed anyway ^_^... Still, might be worth it to put some tamper detection right after the root fs is mounted (i.e. an md5sum check of your entire boot partition)

    In any case, I've used such a laptop on a day-to-day basis for over a year and it worked great -- but do expect a huge performance loss on disk access.

    On a related note, there is a warning on http://www.kernel.org/pub/linux/kernel/crypto/v2.4 /README.WARNING to the effect that encryption might be a bit broken in 2.4 kernels. I guess you better stick with 2.2 for now if you really need loopback crypto filesystems...

  • When you are at the partitioning stage there is a box you can check that allows encrypted filesystems.
  • I'm running a mix between the international kernel patch www.kernel.org/pub/linux/kernel/crypto [kernel.org], (accually http://www.kerneli.org [kerneli.org] but it hasn't been alive for some time now) and crypto api [sourceforge.net] (which is a branch from kerneli.)
    Something needs to be done about the block size problem - the solution from cryptoapi doesn't seem "the right way" ;-)

    The best things about kerneli are the possibility to choose between different encryption algorithms and that it's not filesystem dependent. Though I miss the oppertunity to use the encryption algorithms in userspace programs. (Same thing about the digest algorithms, do thay have any function except for enlarging the kernel size?)

    I'm currently testing a pam module that mounts kerneli encrypted home directories, release scheduled a few weeks into the future.

  • normal:
    cryptoloop (cryptoapi), loop-aes, cryptfs, bestcrypt, crypto-patch (up to ~2.4.12, you have to change the Makefile -> better use cvs-cryptoapi)

    steg:
    stegfs, vs3fs

    network:
    cfs, tcfs, sfs, vpn solutions

  • CryptAPI (Score:2)

    by jd ( 1658 )
    There's a readme in the kerneli 2.5 stuff, pointing to a different directory. In that directory, there's a bunch of patches titled "cryptapi", for 2.4.x and 2.5.x. And they seem VERY current. And much better maintained than kerneli.


    I'm not following the lists at the moment, but I'd hazard a guess that cryptapi is the replacement for kerneli, which has been in a coma for ages.

  • Lame, Windows XP implementation (Score:4, Interesting)

    by Zeinfeld ( 263942 ) on Thursday November 29, 2001 @12:21PM (#2631564) Homepage
    So I happily install XP Professional because it has the ability to use encrypted file stores. This would be just the thing to carry files from one machine to another on a 128Mb Compact flash or so.

    Bzztt... wrong...

    Turns out that NTFS cannot be used on removable disks, even though the NTFS semantics are better suited (think what happens when a disk is unmounted unexpectedly.

    The main reason I use an encrypted disk is that I have a lot of client sensitive info on my machine, including high level strategic plans for a Nasdaq 100 company.

    Encrypted disks should be used as a matter of course on machines used by lawyers, doctors, accountants, anyone with a professional confidentiality duty. Laptops get stolen, machines get sold with confidential information still on the drives.

    I am more skeptical about the need for encrypting file systems for geeks, after all most sysops would do better to keep less secrets rather than more.

    • Turns out that NTFS cannot be used on removable disks
      I use NTFS on my zip 100 disks all the time. Its not that it won't work on removable disks, its that they disable the use of NTFS on small disks (and i guess flash cards? never used them.). I have not formated one on WinXP yet, but I have on WinNT4 and Win2000.
      • I use NTFS on my zip 100 disks all the time. Its not that it won't work on removable disks, its that they disable the use of NTFS on small disks (and i guess flash cards? never used them.).

        Could be that the limit is 128 Mb, I tried with a 64Mb compact flash, that is the largest I have so far. A friend told me they had problems with a 128Mb in a Nicon Coolpix 900 (he could only see 80Mb) so I didn't get any larger ones.

        The help file is less than helpfull

    • So I happily install XP Professional because it has the ability to use encrypted file stores. This would be just the thing to carry files from one machine to another on a 128Mb Compact flash or so.

      You'd be better off with PGP7 and it's PGPdisk utility. I use it all the time to move around an encrypted file system on an Iomega Zip disk. The down size is that you need to have PGP installed on every machine you intend to use, and a way to move your keyring around too.

  • twofish loopback encryption (Score:2, Informative)

    by aCC ( 10513 )
    Twofish loopback encryption [in.tum.de] is a module to encrypt loopback devices "independent[ly] from the medium on which the filesystem is stored".

    This is quite different to quite a lot of other methods. It allows to backup encrypted files to e.g. CDROM and still have them mountable from there. Works quite well.

  • StegFS? (Score:2, Informative)

    by lnxslak ( 524709 )
    What about StegFS [mcdonald.org.uk] is a steganographic filesystem for linux. It encrypts the data and hides it. Although it does not work with 2.4.x kernels, a decently patched 2.2.20 kernel should do well enough. If that's not you particular cup of tea there is always cfs tcfs [www.tcfs.it].

    Fighting for Peace, is Like Fucking for Virginity
  • I use loopAES:

    http://loop-aes.sourceforge.net/

    It works wonderfully, and has worked on every kernel I've tried it on. It doesn't patch the kernel and require a rebuild (except that it requires you do not use the kernel's standard loop device).

    It requires a little bit of extra work in that you need to patch util-linux. I used to use cfsd, but I've not been able to get it to work on recent kernels, so I've moved my encrypted volumes to loopAES. I've had no problems at all with it.

    Jason.
  • Don't forget that if you put your laptop to sleep and it's stolen in that state that your encrypted filesystem may be left wide open.

    Unmount encrypted filesystems before you sleep the laptop and put a password on your screensaver in case you get lazy. (don't count on a password-protected screensaver to protect you though -- maybe someone will create a screensaver that unmounts any encrypted fs and prompts for the access password... :)
  • I started poking around, and at http://www.kernel.org/pub/linux/kernel/crypto/v2.4 /README.WARNING [kernel.org] there was a url listed for "more recent patches. Going there [kernel.org] revealed stuff for 2.4.6, 2.4.8, 2.4.10. 2.4.15, and 2.5.0... I plan to check it out myself when I get some free time.
  • when was the last windows EFS release that was not just a vulnerability patch?

    by the way, when was the last vulnerability patch?
  • I have been using this for a year. It works on windows and linux, ok its not free, well infact the source code for the linux one is available for all. It works as a loop back fs, so the "containers" (fikes) for the encrypted data can be copied between machines easily. What filesystem is on the container is up to you, ext2, reiserfs or even msdos. It works on the lastest kernel versions, and has very active support, from jetico and the community. It works using kernel modules so no patching of the kernel is required, having the data in regular files, means its easy to get rid of too. Anyway give it a try http://www.jetico.com

    James

  • I'm trying to do this (Score:2, Interesting)

    by malxau ( 533231 )
    I've been working on a project that would be able to do this (one day - hopefully) on Windows, Linux, Solaris, and Mac OS X (Those being the platforms that I have.)

    I'm not a crypto whiz and am having serious trouble finding enough information about how filesystems work in order to implement all of the required interfaces. Does anybody know where this information is, or should I look through Linux/BSD sources - and hope that BSD is applicable to OS X?

    My current version is pretty much a library that allows you to like apps against it, but doesn't support native operation. The next release will add networking support, but I really need to go native to make it useful to people.

    Also, can anybody help decrease the usefulness of the algorithm for decryption so that I can GPL the thing? You can see what I've done from here. [unimelb.edu.au]

    - Malcolm

Slashdot Top Deals

"Pull the trigger and you're garbage." -- Lady Blue

Close