Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Encryption Security

Encrypted Filesystems With Linux? 185

Posted by Cliff from the how-about-2048-bit-keys-on-your-data dept.
PhracturedBlue asks: "There are lots of ways to encrypt a filesystem (via loopback, ppdd, CFS or CryptFS), but all of these options appear to have their faults, be it poor performance, lack of features, or not being actively maintained. So are there any other options out there, that provie quality FS encryption with reasonable performance? So, are there any other viable options, besides the ones I've found? Are there any actual benchmarks of actual performance for the viable options above (I guess the viable ones are loopback, CFS, TCFS, and PPDD)? How about systems using the AES-winner Rijndael (I know Loopback Encryption and possibly TCFS and PPDD can use Twofish, but isn't Rijndeal supposed to be one of the faster encryption methods?). I've seen the recent Slashdot article, and it didn't really address the above questions."

"First let me say that I know little to nothing about cryptography, and I wouldn't know the first thing about good vs. bad options, so any statements I make here are based on what I've read and may be completely erroneous. What I'm looking for a way to secure my (Debian) Linux laptop, since physical security is an issue (I can't keep it locked up in my house all the time). So I went out looking for a way of encrypting my filesystem.

The easiest method appears to be to install Loopback Encryption, but from what I can figure out this is a bad solution because (a) its very poor performance, and (b) there is no way to do key authentication. Another option is CFS (a quick howto can be found here), but this is also reported to have poor performance (even with blowfish, or the NFS related TCFS) and it also appears to be abandoned. (Okay TCFS may not be abandoned, but it hasn't been updated for over a year). People seem to rave about CryptFS, but this appears to be a prototype developed for a research paper that has gone no further. Of the last real options that I've uncovered PPDD (which is a device-driver rather than a filesystem) seems like it may be the most promising (though it doesn't seem to have been updated since January, and I can find no indication about testing it with the 2.4 beta kernels)."
This discussion has been archived. No new comments can be posted.

Encrypted Filesystems with Linux? More

Encrypted Filesystems with Linux?

Comments Filter:

  • Re:Encryption Needs (Score:3)

    by Garc ( 133564 ) <jcg5@po.[ ]u.edu ['cwr' in gap]> on Friday October 13, 2000 @08:56AM (#707800)
    Blowfish, and presumably twofish, are very fast after they generate your sub keys. Basically, they take your key and encrypt it multiple times, and use the results as keys for the actual encryption/decryption scheme. Once you get the sub key overhead out of the way, encyption/decryption is pretty quick. I wrote a paper [garc.net] on blowfish last year for my school [cwru.edu]'s Cryptography course [cwru.edu].

    garc
  • Speaking of encrypting filesystems, has anyone tried encryting the swap dir? This is one place people always worry about data being compomised. Secure programs sometimes lock RAM while fiddling with passwords so they can't be swapped out.

    What if you encrypted swap and kept the key in locked RAM with the kernel? If the machine crashes or reboots (perhaps into a different OS or a boot disk), the swap is unreadable as the key has been lost. The user would never need to see the key -- it could be generated at each boot by the kernel and never revealed.
  • Are you trying to prevent someone who steals it to gain access to information or render the laptop useful. A format would take care of the second one pretty quick, and I still haven't figured out who has information so important that it needs encryption(on a personal device, not corperate or gov.)
  • So it uses encrypted public keys ...

    ... your files are as safe as the encryption of the PKCS files.

  • WHoops.. messed up the link specification. Should have previewed :(

    go HERE [cam.ac.uk]

    -Laxitive
  • There are hard disk controllers with hardware encryption. That way, even if they take your hard drive, it still encrypted.

    I believe the encryption phrase is in EEPROM, and a utility is provided to change it. If you change it, your hard drive is instantly unreadable. Forever

    When the FBI is trying to batter down your door, you run the utility, change the key and surely you will do better than Oliver North.

    Hardware encryption like this is much faster than software encryption and has no overhead on the OS. The controller looks like a regular IDE or SCSI controller to the OS.

  • I tried the same thing. Loopback encrypted /home on a samba server. I know the cleartext network traffic and the windows client defeats the purpose somewhat, but I was more worried about someone burglarizing my computer than breaking into my network while it was running.

    -Performance wasn't bad on a K6-2 400. With 128bit Serpent I got 1 MB/s vs 4.5 MB/s for unencrypted files.

    -The 2GB filesize limit means you can't make one big loopback filesystem for the whole disk.

    -Patching and recompiling the losetup and mount utilities (part of linux-utils) is a pain. Make sure the linux-utils version exactly matches the one that the patch has.

    here's some help for people who want to try it:
    Linux kernel crypto patches [kerneli.org]
    encrypted loopback HOWTO [sourceforge.net]

  • Re:iButtons (Score:3)

    by rjh ( 40933 ) <rjh@sixdemonbag.org> on Friday October 13, 2000 @10:27AM (#707807)
    I don't think the iButton is supported under Linux, though. Check out Schlumberger (here [schlumberger.com], here [cyberflex.com] or here [cryptoflex.com])smart cards; apparently, they have a Linux SDK out somewhere. Pretty slick cards, too--support CRYPTOKI (PKCS-11) pretty well, nice form factor (same size as my credit card), ISO-7816 interface. Getting them set up is a little bondage-and-discipline, but once you get past that they're sweetness and light.

    No, I don't work for Schlumberger. I've just been doing some dev work on them (for Win32) and have been moderately impressed with them. They're the best crypto tokens I've used so far.
  • you forgot built-in compression as well.

    When 40GB hard drives can be had for $100? Who needs to compress?

    --

  • Couple of things to consider (Score:1)

    by Anonymous Coward
    Encryption Algorithms take on a couple of forms - Block encryption where each block is encrypted without regards to previous blocks, and feedback algorithms in which the encryption of any particular block depends on the previous block.
    Unfortunately, block encryption provides very telling patterns (for example spaces in text or 0s in numbers) that make attacking/breaking the encryption pretty easy. So it's hardly worth doing.
    Feedback, while more secure, make random access a nightmare. Imgagine a SQL query where in order to read and decrypt row 900, you had to read the data base up until that point, for each and every row in the result - it's pretty near impossible to get good performance.
    In general all out encryption of an entire drive probably would only be practical with hardware devices. And even then you can have 1 key for the entire drive, which once unlocked anyone can get to (ie across your network) or you can encrypt only a partition or second drive and all of your data ends up in the clear in the swapfile anyways (because that's how computers work).
    What information are you trying to protect? Financial records? get a stand alone encryption program and encrypt the files, keeps joe average out. Bomb plans to blow up the white house? Get a 'B' rated computer, stay off any PC. Don't forget, several countries have the ability to read your PC screen through walls at 1/2 mile. I read somewhere the only secure computer was one that had been ground into sand and spread out on a beach.
    I worked for a company that has a reasonable way to make entires disk encryption practical, but NSA keeps pushing them out of the market (probably means they have somethting good). Actualy, I am on a contract back to that company to demo this on Windows for and SBIR now. Maybe, if NSA leaves them alone, they can finaly bring this to market.
  • [[The other advantage is that hackers can't touch it. What if a hacker recompiled the binaries for your software encryption with a backdoor? Bad news, your formally encrypted partition is now fully accessable to the hacker or anyone who is aware of the backdoor. With a hardware solution, it's almost impossible to trojan and/or modify the hardware.]]

    The backdoor code in your software would most likely intercept the password as it is entered by the user. How do you suppose a password (key) would be passed to a hardware device? By pure hardware? A HD with a keypad attached would be quite a sight and rather impractical for remote access.

    My guess is that you would still have to enter your key/password into a piece of software that would pass in on to the (software within) the hardware.

    So, that just leaves the speed advantage.

  • Safest Idea (Score:3)

    by OmegaDan ( 101255 ) on Friday October 13, 2000 @02:20PM (#707811) Homepage
    Probably the best thing would be to stop downloading porn altogether :)
  • It's not free software, but BestCrypt (here) [jetico.sci.fi] works really well for me on both Linux and Windows. I use it to encrypt removable media and can mount them under both OSes. It's basically free for non-commercial use.

    I used to use TCFS but their efforts seemed to lag behind after the Linux 2.2.x kernels came out and I subsequently dropped off their mailing list.

    There is supposedly a set of Linux patches that are available for embedding crypto of some sort into the Linux kernel. These were prevented from being placed into the Linux source tree due to U.S. export restrictions. Now that those restrictions have been effectively lifted I haven't heard too much about it. I think it's high time crypto became part of the kernel.
  • Of course, the primary major flaw with encrypted file systems is the software overhead to handle the encryption and de-encryption as data is written/read from the hard drive.

    The ultimate solution would be (and perhaps these already exist) hard drive controllers with encryption chips built in! This would virtually make the encryption transparent without a performance impact. The hardware can be easily manipulated, safely and securely, via utilities on the host machine.

    Thoughts, ideas, or slaps in the face?

    --Cr@ckwhore
  • Bcrypt is the BOMB. I also have large containers with no problems.
  • I have used StegFS and highly recommend it. But for non-encrypted data it has a special feature - it overwrites all deleted files with random bits. Thus, you get enhanced security even if you never open the encrypted levels of the filesystem.

    The computer is also very usable even when the encrypted layers are closed, so you don't need to expose yourself by logging into the encrypted layer each time you log into the system.

  • An AC made this point more succinctly, but I will reiterate with examples: *nix has had process control from the (very?) beginning. Next time you have access to a *nix box, run "ps -axf" or "ps -ef" depending on the version, and you will see a very similar list to what you see in Win2K. I have ftp, http, dns, and various others. Each proccess has it's PID, and by default runs at "nice" level 0. The round-robin scheduler then givees each process it's due allotment of CPU time, if it asks for it, and everything is hunkydory. However, if you have a process that you don't want to be interuppted while it is executing, you can "renice" the process, and set it's nice value lower. The range is -20 to +20, with the lower values bein executed with a higher priority. This is ecspecially (sp?) useful when running an mp3 player of some sort, as by giving it a lower nice value, you can (virtually) garuntee that it won't skip. Of course, the reason to set a higher nice value is for processes such as rc5 or seti@home, where you don't care how often it is preumpted, as long as you don't get interuppted in your work-flow. To sum up:by having per-process control on a forty point scale, you are enabled (management speak!!) to proactively fine-tune your machine. And *nix has been able to do this since the seventies. Apparently (and I will admit to ignorance) Win2K (what you were wishing *nix was like) only has the ability to control whether your forground or background apps have priority, without getting more detailed than that. Surely, you can see why the (here it comes again) *nix model is better. For a better and less rambling explanation of how process control works, I direct you to almost any paper/book/HOWTO covering (this is the last time, I swear) *nix shells. I hear the Linux-Newbie-HOWTO is particularly informative. HTH.

  • The Big Problem with most of the would-be solutions (note: I use CFS, and find it quite satisfactory for my purposes, despite the weaknesses) is that you get to choose between only two options:
    • You can either "mount" the resultant FS publicly, so that anyone on your system can see it, or
    • Each and every program that wants to go after encrypted data needs to individually explicitly include cryptographic support to read keys and access/update encrypted data.
    Neither of these are terribly satisfactory. The first approach leaves a lot of stuff visible in plaintext form, whilst the latter pushes a substantial burden for encryption support into each and every program.

    As is nicely outlined here [harvard.edu], the Plan 9 [bell-labs.com] operating system provides the ability to do this Another Way, using the concept of namespaces. The basic idea is that the "file tree" is no longer a global thing, but is, instead, localized to processes.

    In effect, I might, from my shell, run the command:

    mount -t crypto /home/cbbrowne/encrypted-stuff /mounts/plaintext

    This results in the encrypted stuff in my home area getting attached to the file tree under /mounts/plaintext

    The two clever things about this are that:

    • /mounts/plaintext is visible to the shell that invoked the mount, as well as to its children.
    • /mounts/plaintext is not visible to any other processes.

      Entertainingly, perhaps not even to root.

    Why should this be considered relevant to Linux? Because there has been considerable discussion of namespaces in relation to the Linux kernel. [iu.edu] It won't be in 2.4, but it's the sort of thing Alex Viro [linuxcare.com] is liable to consider experimenting with in 2.5 or some such version.

  • Don't bother unless... you start off with a virgin disk and encrypt your page files

    Or buy enough memory that you don't need to set up swap.

    But then you've got to worry about someone being able to suck the memory out of your machine while it's running. Does the kernel crypto patch zero and randomize pages after their contents are no longer needed? And what about the editor you're using to work on that sensitive file? After you close a file, does it zero or randomize the memory that was occupied by the file? And does it return the memory to the operating system so those pages can be reused -- and thus overwritten with other, different data? Does your editor keep a backup in /tmp?

    Sound kinda paranoid doesn't it?

    The level of security you need depend upon who's going to go after your information, what kinds of resources they have (both time and money) to expend breaking your crypto, and how valuable your secrets are to them. If you're a spy or you're committing other serious crimes that the federal government would be interested in, then you need to be worried about Big Brother's resources, and maybe the questions above aren't so paranoid.

    Me, I'm more worried about the odd scuzzball swiping my laptop, and getting their hands on my credit card numbers, address, phone numbers, SSN, and that kind of thing. Even this might be overkill -- the average opportunist laptop thief is probably more interested in the value of my hardware than what's on my hard disk. To put it another way, my secrets aren't worth much to anybody with the resources to do any serious cracking.

    That doesn't mean I don't want to protect my secrets. I keep a small encrypted partition on my drive and store my sensitive/personal stuff there, but I don't worry about my swap file or whether my editor flushes its memory. I'm comfortable with that level of protection.

    --Jim
  • Well, if what you want is heavy duty commitment to encryption, security of your computers' data AND swap space, IPSEC -- and what was that other project? F(ree)/SWAN? -- yet you want Linux binary compatibility and throw in it that it must be Free Software, at least as secure as Linux, more so actually, and offers full IPv6 support now to boot, then consider OpenBSD. [openbsd.org]

    It's a UNIX and it's decendant of the BSD code, which means that it offers a very mature networking code base.

    --
    Me pican las bolas, man!
    Thanks
  • A wiiiilld theory would be that the plaintext is the line in paranthesis below =).
  • Even more fun if your keyboard have long enough cable to place the keyboard infront of the machine beside it, while still plugged into the original (-:
  • Me. I keep my financial records on my computer. I don't want someoen wandering up, sitting down at my computer and seeing "oh hey he's got 8K in bt stock." or "oh hey. I can read his love letters with his girlfriend." Almost everyone has something worth encrypting. As almost everyone makes money, pays taxes, etc. If you would lock it up in a filing cabinet then you should encrypt it on disk.
  • I hope your swap file/partition is encrypted, or at least disabled when you access those encrypted files.

    Imagine the following scenario:
    You encrypt your sensitive data, then you open it. Now you presumably have it buffered in memory by the program you're using it with (be it emacs, gnumeric, abiword, etc.), and you begin to swap... Your sensitive (unencrypted!) data is now in the swap file and can survive there for a VERY long time (after writing and rewriting and rewriting many many times). Large parts of it are probably even located in a similar spot in the swap file, making it easy to find large chunks of it if you find a block. Whoops. If anyone -really- wanted that data, they would have it.

    Of course, if your encrypted data isn't really that sensitive, no one will want it enough to waste time analyzing the drive to find it. :)

  • No, no, see (Score:3)

    by xant ( 99438 ) on Friday October 13, 2000 @08:59AM (#707824) Homepage
    In Linux, the source code is open, but your data is securely locked away. In Microsoft, the source code is securely locked away, but your data is wide open.
    --
  • The latest international kernel patch does indeed support AES (Rijndael).
  • but even if they know what files are encrypted, with 1024/2048 bit, it doesn't matter either way; they're not getting at that data. Sure, there are caching and disk access issues with encrypting single files, but those notwithstanding, locking one file behind your wall should be as secure as locking the entire drive behind it
    _________
  • Oops. My mistake, now I'm embarrased. =) You were refering to the original poster, not the one in top of you.

  • Re:How I encrypted my laptop (Score:3)

    by hackerhue ( 182083 ) on Friday October 13, 2000 @09:02AM (#707828) Homepage
    I set up my keyboard to use the Dvorak layout, and didn't change the key caps around. It's better, because a lot of people know how to touch-type on QWERTY, but most people don't even know about the existence of the Dvorak layout. Here's "su":

    # og

    and "cat /etc/passwd":

    # jay z.yjzlaoo,e

    I don't think that it really works that well, though. It just slows them down and really annoys them.
  • Actually, there are many reasons IMO:

    1 - Browser history files. These are many many many files, not just one or two. Would you enjoy it if someone stole your laptop and the was able to comb over which web sites you frequented? I sure wouldn't.

    2 - E-mail. Same thing as above. You want someone reading your e-mail? No thanks for me.

    3 - Personal IP (Intellectual Property). This being anything from a paper you're writing for school (someone else in the class might be happy to have a full or even half finished paper) to the new spy thriller novel you're almost done with.

    4 - Personal documents. Again, I wouldn't want someone reading my budget, or my list of goals for the future ("become a fairy princess"). I also keep inventories of my posessions (my comic collection, my electronics, the hardware on all of my computers, etc) on my computer. If someone were to see that, my house would be a juicy target to break into.

    5 - Any other computer file that you consider private. Anything from your goat pr0n to your "top secret Quake 3 config file".

    Using an encrypted file sysytem is the best all in one solution, rather than encrypting individual files. This way, rather than individually encrypting 100 files, you can just move them to the encrypted partition, and you've got security without the hassle.
  • ...
    The most practical solution to the problem of DRAM data retention is therefore to constantly flip the bits in memory to ensure that a memory cell never holds a charge long enough for it to be "remembered". While not practical for general use, it is possible to do this for small amounts of very sensitive data such as encryption keys.
    Will we be seeing DRAM driver-logic that actually does that in hardware while it refreshes the memory????

    --
    Americans are bred for stupidity.

  • Is there anything that can really effiectenly encrypt? Quickly and usefully?

    I dont think there is anything.

  • It'd be nice to see a disk controller with encryption capability. IANA hardware engineer, but I'd bet that it would be trivial to reprogram a disk controller capable of doing RAID5 to do hardware encryption (also).
    How about a "modified" RAID whose one disk is actually a "one-time pad" key for the whole data? Just remove that drive and the whole disk set is unusable.

    Of course, with such a setup, as my mother used to tell me when I was a kid, "Backup early, backup often!!!"...

    --
    Americans are bred for stupidity.

  • I have the same problem with the y and z switched.

    (I temporarily map my keyboard to german to get my homework done.)

    It only takes a couple minutes to get used to. But it is still funny as shit to watch idiots get hung up with such things on their computer. (Try some of those creeping/jumping icon programs for windows!)


  • Moderators and crack, what is the connection?

    the above post got a +2 insightfully. It links to slash and geek porn, instresting yes, insightfully no.


  • Obvious justifications: work files, 3rd party info (Score:3)

    by coyote-san ( 38515 ) on Friday October 13, 2000 @10:49AM (#707835)
    To pick just one obvious example, any files you have from your employer should be on an encrypted FS. Even the company's phone list can be considered "confidential" if it includes employee's home address and unlisted phone numbers. Anything legally recognized as IP (non-published source code, client lists, etc.) should definitely be protected.

    You could PGP each file individually (hah!), or just encrypt the entire directory tree/FS.

    If you have information on third parties (e.g., financial or medical information on clients) then encryption isn't often isn't even an option - it's <b>required</b> by some of the recently passed privacy laws.

    Overall, I would say that it's a tossup whether a fixed system (at either the office or home) needs encrypted filesystems, but there's no doubt that laptops need them.
  • What happens when ld.so gets corrupted? You say fuck it?

    I grimace because recovering is going to cost me some spare time. Then I reboot from a floppy, repair my / partition, and continue on about my business. You see, I actually keep my /home on a different partition from /, so I can (or could if I felt like it) encrypt my private files without needing to encrypt critical system files. The Unix file system is set up with mountable partitions that way specifically so that different classes of files can be treated differently.

  • There is a Linux package here:
    http://www.ibutton.com/software/1wire/wirekit.ht ml

    I haven't had much time to play with it tho, so I don't know it's capabilities,
    but I seem to remember reading a plain (memory-only) iButton under linux.

    Those cards look pretty spiffy, too. I might have to pick some up sometime...
    Just out of curiosity, how durable are those cards? Can they survive being in a wallet?

    --K
    ---
  • That's thre right way only if you subscribe to the kitchen sink approach to system design.

    What Linux really needs is better mechanisms for stacking file systems and implementing file systems in user code. Then, different people can implement what they need on top of a standard Linux system.

  • How I encrypted my laptop (Score:4)

    by Hairy_Potter ( 219096 ) on Friday October 13, 2000 @08:32AM (#707839) Homepage
    I just removed the keys, and then replaced them incorrectly, foiling anybody but a touch typist. For instance, some cracker gets my laptop and tries to su, but they type this instead:

    # ay
    ay not found

    Then they try to get to my /etc/passwd file, but end up typing this:

    # fs .wrx.osaaqes

    Really, this work!
  • I believe the Coda file system implementation for Linux allows you to hook into open/close requests. This ought to allow the creation of user mode tools for transparent file-level encryption and may be a much better approach than the current NFS-based or kernel-based methods.

    There is actually a Perl user mode file system that's based on those hooks (PerlFS?).

  • Even if the file system is encrypted it won't do you a whole lot of good if your system has weak security to begin with. For example say you have your laptop stolen and you fs is encrypted. If your log on has crappy security what would it mater? All someone would have to do is log in them boom there in and all the work did was for naught.
  • it's updated in realtime. The processes are complete with CPU time, current CPU usage in percent, and memory usage. All that is updated at an adjustable interval (500, 2000, or 4000 milliseconds, or paused). I'd like to see this implemented in the *nix world.
  • I've been using E4M for NT/95/98 for a while now and recently went back to their page to check for a newer version, and I was suprised to find that they mentioned working on a linux version. I'm not sure how old that statement is, but perhaps a little encouragment could help. Plus, they have the source for the winXX versions, though they still haven't fixed the pesky win98 shutdown bug...but it was the best solution I found for winXX
    check here E4M [e4m.net] for the goods

  • Encryption Needs (Score:3)

    by Gefiltefish ( 125066 ) on Friday October 13, 2000 @08:34AM (#707844)
    It seems like everyone is interested in encryption lately, particularly with fascinating books like "The Code Book" being available on the market. It seems like level of encryption should be a core issue here.

    For example, if we're talking about keeping marketing people from getting on your machine to try and play Solitaire, your encryption needs are minimal and not processor-intensive. However, if you're worried about someone stealing your laptop, taking it to a lab, hacking into it with vast resources and smarts, and extracting your highly sensitive information, you will need more powerful encryption that, by its nature, will slow down the machine in general.
  • You are thinking of something else. The user wants to be able to have his files not be read by others not his program sorces. He cares about privacy.
  • I really wish there were some simple way to encrypt data to write to a CD-ROM. Actually I found this [freshmeat.net] project to produce encrypted CD data on Freshmeat awhile back. This patch only encrypted the files themselves not the filesystem (i.e. all filenames are visible) which is very much suboptimal, plus there were other buglets. Now it appears that the project pages are all history.
    I even volunteered to try and help out with the current block limitation on the international kernel patch to allow using CDRs but received no reply to my email. Sigh.
  • is there a possibillity to encrypt or zip the files by giving them only attributes , the way NTFS does it ?? i find that very good , if you would only encrypt certain files that are very important like password files or user data.. Perhaps if you give CHMOD the +encrypt flag it will encrypt the files and give them another name, like blah.crypt or so.. anyway it would be better if its supported by the kernel...
  • you forgot built-in compression as well. yet another thing on the FS wish-list.
  • As long as you're going for "security-through-obscurity", learn to touch-type on the Dvorak keyset as well. I have a friend who has his system set to use Dvorak by default and no-one can use it who only knows qwerty. He didn't even need to change caps on his (still standard) keyboard, and claims that he gets better words-per-minute than he had before he learned Dvorak.
  • There are lots of valid reasons to want to protect you data. Almost none, however, involve the NSA or other highly skilled adversary trying to break into you machine. Therefore pick a simple mechanism that will not slow down your work. Which ever one makes you happiest.
    Guess what, if the government desperatly wants in, they will get in. If you make a enemy of Bruce Schneier you probably won't be safe. But most people aren't like that and don't care that much.
    I will admit then when I generated my first PGP key I generated the biggest one possible. Then I did a quick reality check -- I had no state secrets to protect.
    Don't forget to balance cost and need. There is no reason for every disk operation to take 50% longer if you are just trying to stop a roomate or random stranger from peeking at your files.

  • So let me get this straight: if you just select "encrypted", it magically "encrypts" the file? What encryption method does it use? Where does it store the key? Or does it just do xor against "Netscape engineers are weenies" written backwards? ;-) File system encryption is kind of pointless if the key is stored somewhere in registry.
    ___

  • Re:BestCrypt for Linux is the Bomb....BUT .. (Score:3)

    by Sirron ( 74501 ) on Friday October 13, 2000 @11:20AM (#707856) Homepage
    I use BestCrypt. BestCrypt uses a "container" file to hold the encrypted data. You can create any filesystem inside of the container, and then "mount" the container (of course using bestcrypt to do the mount). The file can be encrypted with a variedy of algorithms including des, twofish, and blowfish (but no rijndeal yet). The container can be copied and moved like any ordinary file (including onto CD, zips or floppies). I have a laptop (PII 266) and I don't see any performance problems. I can play MPEGs, RealVideo, and MP3's from the encrypted system.

    But beware of a problem that I have. When you create a big (over 170MB) container, and create an EXT2 filesystem inside that container, once the data exceeds 170MB the system hangs (SOLID!!!!). I don't know whats magic about 170MB, and I have tried to debug but to no avail. It happens every time. And for me it has happened under RedHat 6, Mandrake 7.0, 7.1, and beta 7.2.
  • I used to do that to end-users keyboards when I worked at a large company. Except I would only switch the "m" and "n" keys. It was hilarious. You'd see them typing along, then hit one instead of the other, backspace, do it again. Backspace, look carefully, and do it again.

    After a couple of times, they usually figured it out.

    Jordan
  • there's a problem with that: the interesting data sticks out like a sore thumb because it's encrypted. With an encrypted file system, an attacker doesn't even know where to begin looking for the interesting data (neglecting the obvious "on the encrypted filesystem somwhere")

    Bill - aka taniwha
    --

  • Sorry, don't you mean Sawmill *with* Gnome for Xwindows for Linux? Now, out of those 3 layers, which should we remove? Should we integrate XWindows (or equiv) into the kernel and wind up with the infamous stability problems that Windows 9x and NT have? By all accounts NT is stable as hell if you use the standard VGA driver, but wandering too far away from it results in a crash happy machine (what your rant was apparently against). Should we integrate Gnome into XWindows (or equiv)? Without even going into the KDE vs. Gnome vs. 3 xterms and vi argument, one of the reasons that XWindows has survived this long is that you can update the backend and frontend seperately. Who else is able to use basically the same system for 15 years? AKAIK, everyone from Windows to the Mac has completely revamped their windowing system, and broken compatability by doing that. Whether or not you like the X way of doing things (and I know a lot of informed people don't) it has worked and worked well for many people for a very long time. Fortuntely or un, I don't see that changing very soon. And last-but-not-least, should we integrate Sawmill into Gnome? poof. It's now done. Sawmill is integrated with Gnome. Seeing as they serve two different functions, that is as close as you are going to get.

    To address the last have of your rant, I have never personally experiened a situation where Netscape or Mozilla crashing brought down my system. If you have, and there really was no way to fix it other than a reboot, I will be fairly suprised. On the other hand, I don't see how a nebulous "module priority system" would help or hinder matters. Do you wish to explain further?

    Thank you for your time, and I look forward to reading your response soon.

    p.s. dear nitpicker (not you AFC), I know there is no such thing as Xwindows. I don't care.

  • CFS: best solution at the moment, IMHO (Score:4)

    by Anonymous Coward on Friday October 13, 2000 @09:14AM (#707867)
    The loopback-based solutions have the following drawbacks:
    • The filesystem is a fixed-size file, thus unnecessarily eating diskspace when it's not filled and not being extendable as soon as it is full.
    • It's closely tied to the Linux kernel and thus may break with future kernel upgrades. Not good IMHO for data where security is top priority.
    CFS's major drawback is the performance penalty because it works over NFS (also internally). That said, I don't notice performance issues when working with CFS-encrypted text files on a Pentium I and an AMD K6. Moving data to CFS directories is slow though. BUT:
    • Since it's a userspace implementation, it doesn't depend on kernel code; indeed, you can flawlessly exchange CFS-encrypted between Linux, *BSD and any other *nix flavor.
    • The cypher files reside in the original file/directory structure (with encrypted names) on any filesystem. This makes it possible to burn CFS data on CD-ROMs, use it on DOS-formatted floppies etc.etc. It's also great for backup, because the backup software doesn't need to copy the whole crypto filesystem every time (as with the loopback solution), but only the files that were changed.
    A very promising solution is ReiserFS, as soon as the plugin API has been implemented. Crypto plugins for ReiserFS will probably the fastest and easiest way to securely store data (although CFS data will still remain more portable).

    (remaining anonymous this time because I don't want the whole world to know that there is CFS-encrypted data on my computers)

  • Ugh.
    Oh boo hoo.
    Stick them in a pcmcia adapater and they are *JUST* like any other kind of common flash (smartmedia/compactflash) in a pcmcia adapter.

    What he's saying would work for any flash with a pcmcia adapter.

    Why memory stick? Why 'proprietary?'? Well...
    let's see.

    1) It works in my camera.
    2) It works in my laptop.

    I don't *HAVE* any other devices that take flash...

    what's the problem? Should I have not bought my laptop or camera because they employed 'properietary' flash?
    What about the 'properietary' batteries?

    Shit. Your motherboard uses a 'properietary' chipset... ohh no!

  • Because in order to store data effectively, the actual drive platter stores many bits for each 'bit' you percieve as stored, using various error-correcting patterns.

  • Re:How I encrypted my laptop (Score:3)

    by Apotsy ( 84148 ) on Friday October 13, 2000 @12:02PM (#707878)
    But, alas, I am meerly a pecker

    Reminds me of a guy I knew in college. He was a hunt-n-peck typist, too.

    When describing his typing techniques, he started out by holding up the index finger of his right hand.

    "First year of computer science."

    Then he held up the index finger of his left hand.

    "Second year of computer science."

    Poor guy had to get a Ph.D. just to able to use all ten digits.

  • I have used loopback before and did not find the performance "poor" at all compared other encrypting filesystems in software. However you should know that I have seen a huge performance hit is huge for a supposedly good encrypting file system. I do have rough numbers for scramdisk in windows with blowfish (the fastest it has). 2MByte / sec for a 350mhz PII. All I remember is that the loopback device for linux being at least as fast. If you dont know disks these days - even IDE - can be 10-20 MBytes / sec. It dosent make much sense to me why the scramdisk implementation is the speed it is. It is supposed to be a good implementation. Theoretically i think you can get 26 clocks / byte on a PII for blowfish which is over 10 MB/sec on a PII 350.

  • Re:why? (Score:2)

    by QuMa ( 19440 )
    You might want to get your crypto straight. 1024/2048 bits is the kind of keysizes you use for public key crypto. For encrypting a partition you use symetric crypto, for which anything between 128 and 256 bits keys are enough.

  • Re:why? (Score:3)

    by Silver A ( 13776 ) on Friday October 13, 2000 @09:19AM (#707888)
    It's for keeping your kids (or spouse) out of your pr0n collection - make them build their own.

  • Re:why? (Score:5)

    by rgmoore ( 133276 ) <glandauer@charter.net> on Friday October 13, 2000 @09:39AM (#707889) Homepage

    But why shouldn't somebody want to encrypt their whole partition? There are actually a number of reasons why doing so might very well be a better idea than encrypting selected files:

    • No need for an explicit decision. Rather than having to decide whether a file is worth encrypting, it happens automatically. This is particularly nice if I later change my mind about wanting to encrypt something; there are no bits left on my HD that might contain an unencrypted version.
    • Less effort. Rather than having to encrypt and decrypt specific files each time I want to use them, or remember a specific password to access them, it happens without obvious effort. That's just plain handy.
    • Why not? Yes there is a possible performance penalty, but there's no other particular reason not to encrypt. Just because people have typically not done things that way doesn't mean that we should continue.

    In general, I think that the valid question is not "why should you bother to encrypt your /home partition" but rather "why should the default behavior be to let anyone be able to read the data off the hard drive". The existence of file permission bits in Unix already implies that the right to prevent others from reading your data is a good thing. Why not back it up with a mechanism that can't be trivially avoided by reading the raw data off the disk?

  • OK...so what happens when a pecker like me (that doesn't sound right does it) takes a keyboard and plugs it into your keyboard port. Or, better still, the NSA takes the hard drive platters and does a bit by bit analysis on them.

    I am not trying to be an asshole here, but the question was about encryption.

    As for your technique....I LOVE IT. it has to be the coolest thing since sliced bread. But, alas, I am meerly a pecker (still doesn't seem right), so I'll have to stick with a pathetic BIOS lock. But I did desolder the jumper block from the motherboard....do I get cool points for that?

  • >...not another damn add-on for an add-on for an
    >add-on. Aren't you sick of running Sawmill for
    >GNOME for Xwindows for Linux?

    This is the idea of abstraction, which is at the heart of Linux (and most operating systems for that matter.) For some users this idea may be somewhat disconcerting, but there is no reason for your window manager to have to possess native code for manipulating your video hardware (sawmill running on XFree86), or for your desktop widget collection to know how to manage windows (GNOME/KDE vs. Sawmill).

    If you take your statement as fact, then shouldn't your window manager also be responsible for managing process memory, and disk I/O?

    Abstraction is the beauty at the heart of modern operating systems--my little hello.c application doesn't need to have to include functions necessary for manipulating video memory to print the words "Hello World."

    Now when a layer of abstraction is implemented poorly, of course there will be problems...that's why we love open source...go fix it! But that's another thread all together.

  • Of course - one needs a way to get the key to it - I would imagine that it could be kept on a floppy and inserted at boot time, or whenever the partition needs to be mounted.

    Seems like an iButton [ibutton.com] would be perfect for something like that...

    --K

    ---
  • APC must not have discovered "killall -9 netscape-communicator" yet.

    or by PID. whatever.

    Dirk
    PS: If I haven't posted in months, then am I a troll?

  • CSS! (Score:2)

    by icqqm ( 132707 )
    Hey, with encrypted keys and security through obscurity, nobody will EVER be able to crack the Content Scrambling System! And if that somehow fails, there's always SDMI!
  • Slightly off. Encrypting /usr only gives an attacker more known ciphertext. A good encrypting FS will encrypt the filenames, the directory structure, the whole nine yards. They'd have a lot of known-ciphertext and a lot of cribs ("we can predict there will be an /sbin directory off the /usr directory"), but that's not the same as a known-plaintext.

    Well, if you consider that most Linux systems are installed from standard distributions, the installation process is at least partly reproducable and current Linux FSs don't randomize block allocations, it is very likely that you can come up with know plaintext: just make a /usr partition of exatly the same size as the one founded on the stolen harddisk, do a default-install of the distribution and see to which blocks standard files (preferably those installed very early in the installation process) are allocated.

  • In that case, OpenBSD supports encrypted swap partitions... and it has been through a security audit, so it's probably a better choice than Linux for rEa1 3ncryp73d t0p-s3cr3t g0v3rnm3nt s3CuRiT3e3e3 BAY BEE.

    All kidding aside, though, OpenBSD does come with a pretty good toolkit for encrypted partitions, swap, secure shell, etc, and if you're serious about security it's probably worth a look.

  • Brainbuster (Score:2)

    by Anonymous Coward
    http://www.openbsd.org/27.html
  • ... such as sensitive files, config files, password files, and your swap disk. I'm pretty sure that someone here must have mentionned it, but it doesn't hurt to say it again... ALL FILES AT SOME POINT AFTER BEING ACCESSED GO INTO YOU SWAP! Or have the potential to. And even if I'm wrong, it's still the weak link in all encrypted FS.

    Cheers, Chris
  • Sony may decide to implement things like access controls on Memory Sticks (to do SDMI, for example)

    Ever heard of 'Magic Gate'?
    It's just that. Memory sticks that have been 'enhanced' to provide access control.
    Costs more than a regular stick, too.
    Sony is very supportive of consumer-unfriendly access controls, including SDMI and friends.

    MS tech looks kinda cool (nothing really new tho, just a different form factor) but seems pretty evil, especially if it became dominant.

    --K
    ---

  • ppdd (Score:2)

    by TheCarp ( 96830 )
    hmmmm an encrypting device driver....

    I like that alot. If implimented properly - it could be quite secure. In fact, it would even protect against dedicated hardware looking for stuff on the disk - since nothing ever goes to the disk unencrypted. (the recent BUGTRAQ thread on shred(1) being fresh in my mind)

    I should look into that - its a very cool idea afterall. Of course - one needs a way to get the key to it - I would imagine that it could be kept on a floppy and inserted at boot time, or whenever the partition needs to be mounted.

    Of course - if say /home were kept encrypted - it would mean that remote reboots couldn't be done, unless the disk was left in. (of course the problem is probably more of an issue on a laptop)

    -Steve

  • Encrypted Filesystem on a Sony Memory Stick (Score:3)

    by hussar ( 87373 ) on Friday October 13, 2000 @08:44AM (#707933) Homepage
    This is a topic that has caught my interest lately as well. What I am trying to do is use a Sony 8MB Memory Stick in a PCMCIA adapter card as an encrypted filesystem. I have only done some of the preliminary work (update bin_utils, compile loopback and encryption into the kernel, etc.), so I can't report on how well it worked yet. Has anybody tried this? I figure if it works, I can upgrade to a larger capacity memory stick. Memory sticks are easily carried and hidden, and right now I don't have over 64MB of files to encrypt, so I could conceivably get it all onto a memory stick. Cheers, hussar

    hussar

  • BestCrypt for Linux is the Bomb.... (Score:2)

    by Anonymous Coward
    It works really great and is easy to install.

    http://www.jetico.sci.fi/ [jetico.sci.fi]

  • It is not uncommon that there are bad bits in stored files on tape or floppy. Do any of these cryptosystems permit data recovery... ie, bad bits will be noticed and only cause bad blocks.. rather than generating completely toasted filesystems?

  • All things considered, it probably uses a hash of your unique userid and your password, both of which are stored in the registry (sort of).
  • It'd be nice to see a disk controller with encryption capability. IANA hardware engineer, but I'd bet that it would be trivial to reprogram a disk controller capable of doing RAID5 to do hardware encryption (also). The added bonus would be relief of the main CPU from doing the encryption. Another added bonus would be the ability to encrypt data to *any* device, including tape, CDROMs, CDRs and the like without having to change or modify filesystems modules.

    Another creative option would be to add encryption to the actual physical disk controller (ie, the little PCB on the disk drive itself). I'm not sure what the options are for updating/changing/examining software/keys via SCSI or IDE commands or if a system would be too closed to trust, but it would be another way to accomplish the same thing.

  • Re:My /home is encrypted (Score:3)

    by rjh ( 40933 ) <rjh@sixdemonbag.org> on Friday October 13, 2000 @10:01AM (#707946)
    Another thing to take into account is that you only need to encrypt data, not binaries. Encrypting /usr only gives an attacker more known plaintext to try to crack the key with.

    Slightly off. Encrypting /usr only gives an attacker more known ciphertext. A good encrypting FS will encrypt the filenames, the directory structure, the whole nine yards. They'd have a lot of known-ciphertext and a lot of cribs ("we can predict there will be an /sbin directory off the /usr directory"), but that's not the same as a known-plaintext. Like I said, you're just slightly off, but I'm so anal-retentive about these things that I have to be fastidious about correcting. :)

    Even were it to be a known-plaintext attack, cryptanalysis of any modern, strong cipher is mind-wrackingly difficult. I'd feel safe encrypting my entire HD with 3DES (three independent subkeys) and turning a copy of the contents over to my business competitors, the Feds, organized crime, you name it. (Wouldn't turn the originals over--scanning electron microscopes can pick up the most amazing things off hard drives, including cleartext that was recently erased and low-leveled.)

    I don't think they could do it. If any of the above really want to know what's on my HD, they're not going to cryptanalyze my drive, they're going to cryptanalyze me.

    They might Van Eck my monitor, they might grab me in the parking lot and have a fellow named Guido talk to my kneecaps, they might blackmail me, they might... etc.

    Using strong ciphers in strong configurations, you can raise the difficulty of a cryptanalytic attack so high that it's by far more efficient to cryptanalyze the person instead.
  • There is no race condition--in most encrypting systems memory is reserved for use by the swap system, just so that endless cycle doesn't get kicked off in the first place.

    The real reason is performance. I haven't used encrypting swap partitions myself, but I've seen academic papers on encrypted swap partitions which lose about 30% of their speed due to the overhead of encryption. This number should not be depended upon, however--a fast cipher (AES/Rijndael) will minimize the performance hit, as will an optimized implementation, as will a proper method of cipher operation (CFB/OFB are bad ideas), etc. There's room for a lot of optimizations.

    Still, there's going to be an unavoidable performance hit involved with encrypting your swap partition. If you really want to do it, I'd suggest saving your pennies for a few weeks, buying another 256Mb of RAM, and getting rid of your swap entirely.

  • Rubberhose (Score:3)

    by DrBubba ( 119286 ) on Friday October 13, 2000 @10:09AM (#707949)
    You can try rubberhose - http://www.rubberhose.org/. From the homepage description: "Rubberhose transparently and deniably encrypts disk data, minimising the effectiveness of warrants, coersive interrogations and other compulsive mechanims, such as U.K RIP legislation. Rubberhose differs from conventional disk encryption systems in that it has an advanced modular architecture, self-test suite, is more secure, portable, utilises information hiding (steganography / deniable cryptography), works with any file system and has source freely available. Currently supported ciphers are DES, 3DES, IDEA, RC5, RC6, Blowfish, Twofish and CAST." It is not quite true that all filesystems are supported - do not use a journaling filesystem such as RieserFS, JFS or XFS.

  • Some places to start (Score:3)

    by Anonymous Coward on Friday October 13, 2000 @08:46AM (#707951)

    There are a number of good places to look on the web, including:

    Info on Loopback Encryption [kerneli.org]
    Information [ailis.de] on using CFS [replay.com] (useful)
    Faster Option [unisa.it] and another [columbia.edu]. These people [linux01.gwdg.de] have gone about it a different way.

  • why? (Score:2)

    by zephc ( 225327 )
    I have yet to do ANYTHING in my everyday life that would warrant an entire partition being encrypted... and how many people here actually DO something of such sensitive nature that it would warrant needing to encrypt more than a couple files?

    ---

  • Is there a good program (preferably open-source) available to do as much scrubbing as possible of a "tainted" hard drive or portion thereof, given the physical limits of a typical hard drive writing mechanism as described in the aforementioned article?

    Measure the mass of the hard drive. Expose the drive to an equal mass of antimatter. (Dunno whether this qualifies as open source or not.)

  • You can download TCFS (Transparent Cryptographic File System) from http://tcfs.dia.unisa.it/ [unisa.it]

    It seems to be usable, if not blindingly fast.

  • That all sounds fine.
    The post I was replying to simply said 'Don't drives store way more than they are rated for, and why don't drive companies just let us use them?'.

    I wasn't implying anything whatsoever about data recovery.. only explaining where that raw 'space' goes.

  • What I want to see in a filesystem is a combination of Logical Volume Manager, Journaling and Encryption. This would provide quick booting even with large mounted partitions ( a feature of journaling ) the ability to have a volume larger than a single physical disk drive ( a feature of LVM ) and the security of having the data encrypted. I would think that by integrating these features into a single filesystem there may be some benefit in performance over trying to glue seperate implementations of these features together. There, I did the hard part - creating the idea. Now one of you hacker types, please begin coding !

  • Don't bother unless... (Score:3)

    by config.sys ( 243118 ) on Friday October 13, 2000 @08:51AM (#707963)
    you start off with a virgin disk and encrypt your page files. Any disk that undergoes forensic analysis would probably be suseptible to recovering previous data, even if a filesystem is encrypted afterwards. Of course in Windows everything is placed in one filesystem so you don't have to worry about this. FDISK once, install Windows, and encrypt.
  • Are there any Linux distributions that come with support for this out of the box?

  • market research results in: crypto is cool! (Score:3)

    by mrsbrisby ( 60242 ) on Friday October 13, 2000 @01:36PM (#707966) Homepage
    The usefulness of an encrypted filesystem is limited to removeable media and pseudodisks (e.g. those created using the kernel loopback driver). It's been pointed out that many people actually want to encrypt their entire hard drive (or an entire partition) which seems to me to be the biggest waste of cycles there is. But then again, as soon as we classify hard disks as removable (like there aren't hardware locks with similar effectiveness) media it seems to quickly become warrented.

    Of course, this makes a nasty assumption that if you're going to encrypt your disk, you've already got the reason for it. But before I go too far into that, let me quickly point out that network filesystems and encrypted filesystems cannot be considered complimentary. NFS, AFS, and CIFS (all commonly referred to as network filesystems) bear no resemblence with block devices for the very reason that (all) network block devices themselves are extremely ineffecient. Not only is it a waste of bandwidth, but also a waste of cycles for the client (assumed: servers usually have more cycles than clients. if they don't, you have other problems).

    But crypto on NFS and friends all involve themselves with encrypting the network traffic, instead of the individual segments of the files, or the disk-blocks they refer to.

    Mr. Blue mentions that he wishes to encrypt his laptop disk for the sake of security. And being a laptop it can immediatly be considered removable media (snicker). And while the most common reason that laptops are stolen are infact for the hardware (e.g. resale), the lap-jacker may be technologically inclined (as is becoming more common) and wish to sneak out creditcard numbers and other goodies out of the disk before sale.

    So now that I have finally established both cause and reason to encrypt, I can finally target a technological issue of performance.

    By simply creating your disk IMAGE, you are slowing down your system. The goal is to slow it down the least. The the least way is to (on login, presumably) decrypt the entire image into a ramdisk (or other element that will be nuked on reboot - such as a swapfile) and use the decrypted image instead. Before anyone says this is a stupid idea (what if they use a boot floppy), remember that unless you have a lot of ram, your decrypted secrets would be in your swap ANYWAY.

    So bypassing the obvious of disabling floppy boot, the attacker can still take out the hard disk and put it in another machine. Since your data hasn't been wiped by boot (and/or is still in swap), you
    would then need the filesystem and the swap to stay in ciphered form (to make sure all of your data is protected). So in addition, you must keep your swapfile in cipherspace (snicker) so that the bad people can't get there either.

    Which still allows us to keep most of our "work data" in unencrypted space (ramdisk) because when portions of our ramdisk need swapping, they'll be reciphered anyway. And if you weren't thinking about swap, you're faster still.

    So, the short answer (if you read this far, you deserve it by now) is that your filesystem will go as slow as you need it to. That is to say that if you are protecting from your laptop being stolen,
    using a ramdisk for sensitive files is probably good enough (my portable penguin uses PGP to store my ramdisk when sleeping. the ramdisk was 24m which was good enough for my ssh password lists, keys, /etc/passwd and friends). if you need more protection, you're going to go slower (encrypting swap), and slower (encrypting the entire disk), and slower still (embeding your laptop in a cement block and droping it into the ocean).

  • Re:Encryption Needs (Score:3)

    by rjh ( 40933 ) <rjh@sixdemonbag.org> on Friday October 13, 2000 @10:17AM (#707967)
    Level of encryption is really a nonissue. Honestly. Far more important is the level of paranoia in the system, which isn't the same as the paranoia level in the encryption algorithm.

    For instance, if you just want to keep Marketroids away from your PC, an algorithm like DES works fine--at 56 bits of key, it's enough. But more modern algorithms, like Blowfish or AES/Rijndael, provide more security (up to 448 bits for Blowfish, 256 for AES) and faster performance--so there's absolutely no reason to use DES when AES is available.

    The level of encryption is not the same thing as the level of the system. Always use the best encryption you can get; usually, you'll see performance improvements as well as increased security. It's the other stuff that goes into the system which bears more scrutiny--how is entropy collected? How are keys generated? How is authentication handled? How fault-tolerant is it? How tamper-resistant is it?

    All of these questions are very, very hard to answer. I can't think of the last time a major in-use cipher was broken by classical cryptanalytic means. I can think of lots of times in recent history when systems were broken by exploiting problems in areas other than the cipher.
  • Well, somebody has to mention this...

    *takes a deep breath*

    One of my favorite features of Windows 2000 (and NTFS) is its completely transparent encryption (and compression). All you have to do is set the appropriate file attribute... "compressed" or "encrypted", right next to "read-only", "archive", etc.

    Since it's built into NTFS, it's always there, and you can encrypt a single file or an entire drive without worrying about drivers or special partitions.

    I have no idea how secure it is. Given Microsoft's track record with systems programming (and NTFS in particular,) I expect that it's pretty damn good. But I'm sure it's better than nothing, and considering that it's trivial to turn it on, it's hard to complain.
  • You're forgetting a conflict here.. Between encryption and automatic bootup..

    I personally would like it on a file-by-file basis. I need my system to autoboot without a password. So, for example, /usr /etc /var ... must all to be unencrypted. On the other hand,

    On the other hand, my homedirectory should be encrypted. Also, parts of /home/http/ should be unencrypted (Like, my public site.) While other parts must be encrypted until I can log in.

    This means I need at least directory-tree level granularity to control it.

    Any heavier integration would require key-management work first.. For example, if we have file/directory -level granularity, two users are supposed to be able to decrypt and use the file. This will require every file to have some sort of 'authorized keys' list.

    In a lot of ways, this needs the better filesystem metadata and is a LOT closer to ACL lists than you would expect.

  • Definitely susceptible (Score:4)

    by devphil ( 51341 ) on Friday October 13, 2000 @10:21AM (#707973) Homepage

    Peter Gutmann wrote an outstanding paper on recovering data from various media, especially hard drives. Bottom line: once it's written, you can almost always get it back eventually.

    His paper is http://www.fish.com/security/secure _de l.html [fish.com] and is a good read.

    Favorite fact: Freezing your RAM (like, -60 degrees C) makes the data easier to recover. Yeah, that's right, I said the RAM, not just the drives. Go read the paper. :-)

  • Hardware Encryption For Linux (Score:4)

    by n3rd ( 111397 ) on Friday October 13, 2000 @08:54AM (#707976)
    Would anyone know if there are any hardware level encryption devies that Linux supports?

    As with most things, using hardware instead of software is faster (sometimes *much* faster), so this would not only be an answer to the speed problem that was posed, but also it would be very reliable (as opposed to encryption daemons that may die when the system runs out of swap, etc).

    The other advantage is that hackers can't touch it. What if a hacker recompiled the binaries for your software encryption with a backdoor? Bad news, your formally encrypted partition is now fully accessable to the hacker or anyone who is aware of the backdoor. With a hardware solution, it's almost impossible to trojan and/or modify the hardware.

    Ideas on the hardware solutions for disk encrption that are out there, and if so, which ones does Linux support?

  • StegFS (Score:5)

    by Laxitive ( 10360 ) on Friday October 13, 2000 @08:55AM (#707979) Journal
    You might want to look at StegFS. It's a stegagnographic filesystem. It supports multiple "levels" of security, and the nifty thing is that nobody can tell exactly how many levels of encrypted filesystems there actually are. I.e., you can have 3 levels of encryption, and even if the first level is broken, there is no way for the cracker to get to the other levels, or even find out exactly how many levels of encryption there are. Check out stegfs by clicking on this link [slashdot.org]. -Laxitive
  • I've got a PAM module I wrote once. You drop it into your pam directory, and a bit of configuring, and then you can use the ibutton either in addition to, or instead of, passwords.

  • My /home is encrypted (Score:5)

    by abelsson ( 21706 ) on Friday October 13, 2000 @08:56AM (#707982) Homepage
    I have my homedir encrypted with the loopback driver. It's worked like a charm for around a year, when i decided to try it just for fun. No dataloss, no crashes.

    Some observations:
    It's not noticeable slower. I havn't run any benchmarks, but there's absolutly no noticeable slowdown of any kind. Even when copying 0.5gb files between encrypted and unencrypted dirs - the harddrive is the limiting factor, not the encryption algorithm. Granted, i have a speedy CPU (Athlon 900mhz) and only a IDE hardrive (a 7200rpm deskstar). Just if you missed it, The speed difference isnt noticeable. There, now i've said it three times :)

    Another thing to take into account is that you only need to encrypt data, not binaries. Encrypting /usr only gives an attacker more known plaintext to try to crack the key with.

    As for the other drawback you mention, i think having no key authentication is acctually an adantage: There's no fixed header the Bad Guys can use to prove that it isnt a 2gb big chunk of random data. Think plausible deniability. (even tho it's a long shot: i swear officer, i always keep 2gb of the outout from /dev/urandom on all my computers)

    As for algorithms, i think they're mostly irrelvant, as long as you use an algorithm with no known secure holes and a long enough keylength (128bits should be impossible for just about anyone to bruteforce). Cracking fingers (if you just want the data) or the passwords (if you dont want anyone to know you stole it) is most likely a lot easier than bruteforcing the algorithm. So the main advice here: Choose a good long password!

    I havn't tried any of the other available methods, but i doubt any has a lower overhead than the kernel level loopback filesystem.

    I feel reasonable safe about entrusting all my data to the loopback fs encryption. (i even reviewed the code before compiling - just to be on the safe side. Me, paranoid? Where'd you get that idea from?)

    -henrik

Slashdot Top Deals

"If it ain't broke, don't fix it." - Bert Lantz

Close