Encrypted Filesystems With Linux? 185
"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)."
Re:Encryption Needs (Score:3)
garc
Encrypt swap partition, keep key in RAM (Score:2)
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.
encryption!?! (Score:1)
Re:Another option (Score:2)
... your files are as safe as the encryption of the PKCS files.
Re:StegFS (Score:2)
WHoops.. messed up the link specification. Should have previewed
go HERE [cam.ac.uk]
-Laxitive
Hardware (Score:1)
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.
Re:My /home is encrypted (Score:1)
-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)
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.
Re:What We Need in a Filesystem (Score:2)
When 40GB hard drives can be had for $100? Who needs to compress?
--
Couple of things to consider (Score:1)
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.
Re:Hardware Encryption For Linux (Score:1)
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)
BestCrypt (Score:2)
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.
Lets look for a hardware solution... (Score:1)
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
Re:BestCrypt for Linux is the Bomb.... (Score:1)
StegFS has advantages even for non-encrypted data. (Score:1)
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.
Re:Maybe this is already being done... (Score:2)
What's Needed: Namespaces from Plan 9 (Score:2)
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:
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.
Re:Don't bother unless... (Score:2)
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
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
Have Your Cake and Eat it Too (Score:1)
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
Re:How I encrypted my laptop (Score:1)
Re:How I encrypted my laptop (Score:1)
Re:why? (Score:1)
Re:why? (Score:2)
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)
--
AES is supported (Score:1)
Re:why? (Score:2)
_________
Re:How I encrypted my laptop (Score:1)
Re:How I encrypted my laptop (Score:3)
# og
and "cat
# jay z.yjzlaoo,e
I don't think that it really works that well, though. It just slows them down and really annoys them.
Re:why? (Score:2)
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.
Re:Definitely susceptible (Score:2)
--
Americans are bred for stupidity.
hmmmmm (Score:1)
I dont think there is anything.
Re:Disk array controller as hardware encryption? (Score:2)
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.
Re:How I encrypted my laptop (Score:1)
(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!)
Re:Why has /. become a meta-search engine? (Score:1)
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)
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.
Re:why? -- Simple. Because! (Score:1)
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.
Re:iButtons (Score:2)
http://www.ibutton.com/software/1wire/wirekit.h
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
---
Re:What We Need in a Filesystem (Score:2)
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)
# ay
ay not found
Then they try to get to my
# fs
Really, this work!
something based on Coda hooks? (Score:2)
There is actually a Perl user mode file system that's based on those hooks (PerlFS?).
Sniffing (Score:1)
But the best part of the process list in Win2K: (Score:1)
Encryption 4 the Masses (Score:1)
check here E4M [e4m.net] for the goods
Encryption Needs (Score:3)
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.
Re:Encrypted? (Score:1)
Encrypted CDROMs a must! (Score:1)
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.
posible to encrypt or zip files ???????????????? (Score:1)
Re:What We Need in a Filesystem (Score:1)
Re:How I encrypted my laptop (Score:1)
To Encrypt or not to Encypt (Score:2)
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.
Re:Another option (Score:2)
___
Re:BestCrypt for Linux is the Bomb....BUT .. (Score:3)
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.
Re:How I encrypted my laptop (Score:2)
After a couple of times, they usually figured it out.
Jordan
Re:posible to encrypt or zip files ??????????????? (Score:2)
Bill - aka taniwha
--
Re:Linux needs native file encryption. (Score:2)
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)
(remaining anonymous this time because I don't want the whole world to know that there is CFS-encrypted data on my computers)
Re:Encrypted Filesystem on a Sony Memory Stick (Score:2)
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!
Re:Previous data, myth or fact? (Score:2)
Re:How I encrypted my laptop (Score:3)
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.
Performance of file system encryption drivers (Score:2)
Re:why? (Score:2)
Re:why? (Score:3)
Re:why? (Score:5)
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:
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?
Re:How I encrypted my laptop (Score:2)
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?
Re:Linux needs native file encryption. (Score:2)
>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.
iButtons (Score:2)
Seems like an iButton [ibutton.com] would be perfect for something like that...
--K
---
Re:Linux needs native file encryption. (Score:2)
or by PID. whatever.
Dirk
PS: If I haven't posted in months, then am I a troll?
CSS! (Score:2)
Re:My /home is encrypted (Score:2)
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.
Re:why? (Score:2)
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)
Remember to encrypt EVERYTHING... (Score:2)
Cheers, Chris
Re:Encrypted Filesystem on a Sony Memory Stick (Score:2)
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)
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
-Steve
Encrypted Filesystem on a Sony Memory Stick (Score:3)
hussar
BestCrypt for Linux is the Bomb.... (Score:2)
http://www.jetico.sci.fi/ [jetico.sci.fi]
Data Recovery? (Score:2)
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?
Re:Another option (Score:2)
Disk array controller as hardware encryption? (Score:2)
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)
Slightly off. Encrypting
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.
Re:Why no encrypted swap (Score:2)
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)
Some places to start (Score:3)
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)
---
The ultimate drive eraser. (Score:2)
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.)
Kernel Patches for Encrypted FS (Score:2)
It seems to be usable, if not blindingly fast.
Re:Previous data, myth or fact? (Score:2)
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 We Need in a Filesystem (Score:2)
Don't bother unless... (Score:3)
Distributions (Score:2)
market research results in: crypto is cool! (Score:3)
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,
Re:Encryption Needs (Score:3)
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.
Another option (Score:2)
*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.
Encryption and automatic bootup? (Score:2)
I personally would like it on a file-by-file basis. I need my system to autoboot without a password. So, for example,
On the other hand, my homedirectory should be encrypted. Also, parts of
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)
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)
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)
Re:iButtons (Score:2)
My /home is encrypted (Score:5)
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
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
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