![[UP]](/icons/back.gif){kind=icon}
There are many reasons to encrypt your disks. Encryption can be much more secure than physical security. By using an encrypted disk you can defeat the attacks done by power-cycling your machine, booting from another volume and mounting your partitions. Encryption can keep the person which stole your Laptop form poking around in your files.
There are more than half a dozen approaches towards encrypting your disks with Linux:
The Kernel loopback encryption is the classic method of encrypting partitions with Linux. The loopback patch is based on the BSD loopback encryption and was ported by some prominent cypherpunks if I remember correctly. There used to be some steganographic patches to it which allowed you to mount an audio file as a filesystem and your Data in the lower bits of that audio file. Cool stuff, but this steganographic part somehow got lost in the 2.2 upgrade.
To use the encrypting loopback device you have to patch the code into the kernel and then build a patched losetup. Patching the kernel is straight forward because you can use the international kernel patch at http://www.kerneli.org but when building the new losetup you must be careful not to mess with the other tools of util-linux since it can screw up your system badly.
The new loopback encryption patches can use a wide choice of ciphers (DFC, MARS, RC6, Serpent, CAST 128, IDEA, Twofish, Blowfish, but not all ciphers work).
Id Est has patched login so that it enables the user to have multiple encrypted home directorys using the loopback encryption without too much hazzle. From his README:
HOW DOES IT WORK?
If your home directory begins with "/crypt/", the following happens when you log in:
- a free loop device is found.
- you're asked for the size of your home directory (4/8/16/32/64/128/256/512/1024 MB).
- once you've selected a size, a nMB-sized file named "/crypt/(your-id)" is created (ie. /crypt/101).
- you are asked for a passphrase and given your choice of encryption algorithm.
- if this is the first time you've logged in, the password you gave is one-way hashed and put into the file "/crypt/(your uid).x", or compared against the contents of that file otherwise. if the given passphrase(s) don't match, you get bounced out at this point.
- the loop device is set up using the previously created file and the passphrase you supplied.
- if this is the first time through, a ext2 filesystem is created on the loop device, otherwise the filesystem is checked for errors. if no errors are found, the filesystem is mounted on the loop device and you can proceed normally.
- if you're logged in and you log in again from another VT, you're asked for the passphrase, which is compared against the stored passphrase, and if they match, you can proceed. this is to stop somebody who knows your login password, but not your EHD passphrase from piggybacking into your directory.
- when you log out the last time, the filesystem is unmounted and the loop device is freed.
If you use the loopback encryption ehd is a very nice to make encryption easy to use even on a multiuser machine. But you should keep in mind that disk encryption doesn't help if you are using the machine at the same time with different users. So ehd practically only adds security if you use a stand alone machine. Besides security considerations you can't use ehd on a machine with remote-login enabled since ehd doesn't support ssh and su.
You can find ehd at http://members.home.net/id-est/.
CFS is the first free UNIX disk encryption program hacked by Matt Blaze. It hooks into nfs so one feature of cfs is the fact that you don't have to fiddle with the kernel to get it running and cfs is more portable among UNIXes than the other solutions. Another nice thing is that you can use cfs over nfs so that your files won't be transmitted in clear text over the wire.You can find more about the working of cfs by reading the Cryptographic File System under Linux HOW-TO or "A Cryptographic File System for Unix" by Matt Blaze.
CFS supports DES which is insecure because the key is to short, 3DES which can be considered secure but is painfully slow, MacGuffin which is broken and SAFER-SK128 which has a unusual design and is designed by some NSA buddys at Cylink - enough reason not to fully trust this algorithm. But darkstar@frop.org was kind enough to hack Blowfish into cfs and Matt Blaze intigrated it into cfs 1.3.4.
The main problem of cfs even with blowfish is the lack of speed. This results in the cfs being an user space daemon forcing the data to be copied several times between kernel- and user space. If you want to encrypt large amounts of data expect a significant performance penalty when using cfs.
TCFS which is developed at the University of Salerno, Italy claims to improve Matt Blaze's CFS by providing deeper integration between the encryption service and the file system which results in a complete transparency of use to the user applications. But the developers seem to focus much more than Matt Blaze on substituting nfs.
A nice feature of TCFS is that it will allow you to securely share files among the members of a group. On big misfeatures of TCFS is the Fact that it needs kernel patches and that the patches are still made for the now obsolete 2.0.x Kernel. Nevertheless TCFS is under active Development. Another problem with TCFS is that it only supports minimal (read: no) key management. There is some Placebo-key management delivered with TCFS but this is next to nothing using only the login passwort to decrypt the key.
To learn more about TCFS, read the TCFS-FAQ. Since it is from Italy which is part of the free world, you can download it without any problems, go to the TCFS Homepage.
ppdd is a well thought through system for encrypting your disks. Its author Allan Latham describes it like this:
Ppdd lets you use encrypted files systems under Linux. It uses high quality encryption techniques suitable for the large volumes and the long lifetimes of data involved. It is easy to install and use and with just a little care on the users part is very difficult to misuse. Protection is at a "whole machine" level; as soon as root activates the driver then the whole file system becomes usable by all l users subject only to the usual Linux file access permissions. This makes it ideal for stand-alone machines or as a component of enhanced security on genuine multi-user systems. Not surprisingly performance is slower than an un encrypted file system but on a 100MHz Pentium with 32Mb main memory using IDE discs it reduces disc throughput by about 50%; this should be considered accept able for software cryptography.
You can read more about the design of ppdd in the specification or in the ppdd man page. On of the very nice features of ppdd is that you can decrypt devices without kernel-support if needed. And the author has thought extensively about ways to backup encrypted media and shows several solutions to solve this problem. He even made it possible to have an encrypted root partition.
One of the drawbacks of ppdd is that it doesn't use the now evolving Linux crypto-API. But you can use it together with the kerneli.org patch without big hassle. Perhaps you get e few rejections while patching the two together but these are easy to resolve by hand.
You can find ppdd at http://linux01.gwdg.de/~alatham and ftp://ftp.gwdg.de/pub/linux/misc/ppdd. If you want to know how to install ppdd check out ppddhow.txt
I have done some performance testing on a dual PII/266 MHz/256 MB using bonnie. Writing on a encrypted volume takes about twice the time as writing to a plain volume would. But reading from an encrypted volume takes 4 times as long as reading from an unencrypted one.
-------Sequential Output-------- ---Sequential Input-- --Random-- -----Time------
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- -user- -system-
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU sec sec
plain 100 4022 95.0 13628 28.7 4036 17.8 3782 84.7 11663 20.4 286.3 7.0 42.98 13.82
encrypted 100 2609 75.5 5719 17.2 808 23.8 968 44.9 1165 28.1 18.2 5.1 43.40 103.28
While doing this tests my ps/2 mouse reacted like I was using windows :-( but this should be tweakable by skewing with the buffer-cache.
The theoretical background of sfs was laid by Ross Anderson, Roger Needham and Adi Shamir in thair paper "The Steganographic File System". You can grab it here.
The first Implementation was done by Carl van Schaik and Paul Smeddle in a Project called vs3fs. They describe the code they have hacked this way:
Ok, firstly we would like to note that this project evolved from a computer science project that had specific goals and deadlines and thus the code may not be complete in specific areas and still has many bugs to be stomped out.
Briefly, a steganographic filesystem aims to be more than just your every day encrypted file system. It tries to hide the information in such a way as to discredit its very existence. This has been a very difficult task to perform given such a short development time, but we have succeeded in attaining this goal despite a few alternative methods of doing things (read: kludges :).
We present this filesystem as is. We take no responsibility for any damage to disks or data while using this program. I repeat.. this is still VERY experimental and you will probably lose data stored on steganographic partitions. We also hope that some of you will be able to work out some of our problems and perhaps try to modify the structure to be more flexible and to provide better security. After all... thats the beauty of open source :)
We must also note that we use encryption methods that may be stronger than those allowed in your country. We will accept no responsibility for your actions involving your country's regulations.
They had a homepage at http://leg.uct.ac.za/~carl/vs3fs/ with patches for Linux 2.0 and 2.1 but this page is now defunct. Seems they have left university and also left sfs alone.
Peter Schneider-Kamp updated the stuff to 2.2. This stuff can be found at http://www.linux-security.org/sfs/. But since his pages seem to be down to you can get it here.
sfs still has a lot of rough edges and Peter doesn't seem to maintain it actively.
Andrew McDonald and Markus Kuhn did another implementation of the ideas outlaid in the paper of Anderson, Needham and Shamir. They claim that sfs is flawed and this claim seem reasonable.
StegFS seems to be really elaborate and looks to me much more usable than sfs. Since McDonald and Kuhn come the same University than Anderson it seems obvious they tried hard too meet the criterias of the Steganographic Filesystem paper.
StegFS has a homepage at http://ban.joh.cam.ac.uk/~adm36/StegFS/
There is another good-looking crypto file system called
Cryptfs. It is described in "Cryptfs:
A Stackable Vnode Level Encryption File System" and can be
downloaded from here.
But since this side is in the USA which is a country keeping it
scientists from publishing research worldwide, Cryptfs is unusable
for people from the free world untill some dark figure smuggles it
over here.
There is some commercial disk encryption program for Linux called BestCrypt. It comes with source and is available for MS Windows and MacOS too. I haven't tried it yet, check it out at http://www.jetico.com/.
An other comercial Product is called Virtual Private Disk. This
Product seems to be snake
oil, because it claims to protect user files from root
access, which can't be done, since root can get your decription
keys while you are decrypting files.
In addition it is
US-Software which is distributed without export
restrictions. This leads to the conclusion that VPDisk doesn't
contain strong encryption since the export of strong encryption
products from the US is prohibited.