Slashdot Mirror
Encrypted Filesystems With Linux?
"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)."
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 on blowfish last year for my school's Cryptography course.
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.
So it uses encrypted public keys ...
... your files are as safe as the encryption of the PKCS files.
- Michael T. Babcock (Yes, I blog)
WHoops.. messed up the link specification. Should have previewed
go HERE
-Laxitive
I don't think the iButton is supported under Linux, though. Check out Schlumberger (here, here or here)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?
--
Probably the best thing would be to stop downloading porn altogether :)
Free Techno/Jazz/DNB/MI Music by guys obsessed with monkeys!
It's not free software, but BestCrypt (here) 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.
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.
- 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 , the Plan 9 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. It won't be in 2.4, but it's the sort of thing Alex Viro is liable to consider experimenting with in 2.5 or some such version.
If you're not part of the solution, you're part of the precipitate.
Don't bother unless... you start off with a virgin disk and encrypt your page files
/tmp?
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
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.
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.
--
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
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
_________
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":
/etc/passwd":
# 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.
To get something done, a committee should consist of no more than three persons, two of them absent.
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.
--
Americans are bred for stupidity.
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.
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.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
There is a Linux package here:t ml
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
---
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.
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:
/etc/passwd file, but end up typing this:
.wrx.osaaqes
# ay
ay not found
Then they try to get to my
# fs
Really, this work!
There is actually a Perl user mode file system that's based on those hooks (PerlFS?).
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.
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.
___
___
If you think big enough, you'll never have to do it.
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.
The fact that no two snowflakes are identical should tell you something important about God's will.
Bill - aka taniwha
--
Bill - aka taniwha
--
Leave others their otherness. -- Aratak
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.
- 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.
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.
Support the organizations that make up the Global Internet Liberty Campaign http://www.gilc.org/
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.
It's for keeping your kids (or spouse) out of your pr0n collection - make them build their own.
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?
There's no point in questioning authority if you aren't going to listen to the answers.
>...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 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?
I keep trying to pick fights, but I can't shake this Excellent karma.
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!
icqqm [ICQ:11952102]
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.
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.
Free music from Jack Merlot.
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
-- Humans, because the hardware IS the software.
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
---
hmmmm an encrypting device driver....
/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)
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
"I opened my eyes, and everything went dark again"
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
Bureaucracy loves company.
http://www.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).
- Michael T. Babcock (Yes, I blog)
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.
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.
/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. :)
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.
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.
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.
There are a number of good places to look on the web, including:
Info on Loopback Encryption
Information on using CFS (useful)
Faster Option and another. These people have gone about it a different way.
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?
---
"I would say that 99 per cent of what my father has written about his own life is false." - L. Ron Hubbard Jr.
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 cannot apply a technological solution to a sociological problem. (Edwards' Law)
It seems to be usable, if not blindingly fast.
My poetry site welcomes the unusual.
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 !
enough is too much
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.
Why do you bother with gaming on Li
Are there any Linux distributions that come with support for this out of the box?
-- Ed Avis ed@membled.com
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.
/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).
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,
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.
MSK
You're forgetting a conflict here.. Between encryption and automatic bootup..
/usr /etc /var ... must all to be unencrypted. On the other hand,
/home/http/ should be unencrypted (Like, my public site.) While other parts must be encrypted until I can log in.
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.
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 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. :-)
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
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?
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 . -Laxitive
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.
:)
/usr only gives an attacker more known plaintext to try to crack the key with.
/dev/urandom on all my computers)
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