Linux Encryption HOWTO <author>by Marc Mutz, <tt><htmlurl name="Marc@Mutz.com" url="mailto:Marc@Mutz.com"></tt> <date>v0.1.0, 19 November 1999 <abstract> How to set up a Linux 2.2 system to use encryption in both disk and network accesses. This document describes how you can use the International Kernel Patch and other packages to make harddisk contents and network traffic inaccessible to others by encrypting them. </abstract> <toc>   <sect>Introduction<label id="intro"> <sect1>Legal Stuff Encryption HOWTO for Linux Systems Copyright (C)1999 Marc Mutz. This document is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This document is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You can get a copy of the GNU GPL at <htmlurl url="http://www.gnu.org/copyleft/gpl.html" name="http://www.gnu.org/copyleft/gpl.html">. <sect1>I've got nothing to hide In this section I will briefly remind you of basic rules that must be taken care of if you want to use strong encryption, as all of the presented packages in this document support (or even require) it. I will not start the old and always returning discussion about using encryption to ensure privacy. But I want to make clear that not everyone who uses encryption has something (criminal) to hide. Everyone has hidden ``secret'' letters in his life, also those to whom the use of strong encryption seems to imply criminal deeds. Media has pushed the picture of the bad Internet full of organized crime and pornography quite a bit into the brains of all of us, and politicians are happy to find support for banning strong crypto in the name of Justice. But it is important to remember that not everyone using strong crypto is a member of organized crime circles and that the right to protect one's privacy (once?) was a human right. Now, as the above discussion has produced some strange regulations concerning the use of strong encryption, it cannot be over-emphasized how important it is to know the law in your own country: <enum> <item>Am I allowed to use strong cryptography? <item>Am I allowed to use a particular cipher algorithm either for private or commercial use? Do I have to pay licence fees? <item>Am I allowed to participate in the development of software that contains strong cryptography? </enum> Maybe I will extend this discussion in a later version of this paper. As for now, check the following resources to find answers to the above questions: <itemize>  <item>The <tt>alt.security.*</tt>, <tt>alt.privacy.*</tt> newsgroups. <item>The Crypto Law Survey web page by Bert-Jaap Koops at <htmlurl url="http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm" name="http://cwis.kub.nl/~frw/people/koops/ lawsurvy.htm">. <item>The RSA crypto FAQ at <htmlurl url="http://www.rsasecurity.com/rsalabs/faq/" name="http://www.rsasecurity.com/rsalabs/faq/"> <item>The Department of Justice or lawyers if in doubt (likely only interesting for commercial applications). </itemize> <sect1>Aims of this document This document will (eventually, more or less extensively) describe all major development activities around the Linux(tm) operating system that provide encryption features to the kernel. These effords are currently being collected by Alexander Kjeldaas (<htmlurl url="mailto:astor@fast.no" name="astor@fast.no">) in the so-called International Kernel Patch (see below). If some packages described here are currently not included in this patch, I will state that clearly at the beginning of the section that discusses it. This document will not speak about other security-related issues. See the excellent <htmlurl name="Security HOWTO" url="Security-HOWTO.html"> for that. <sect1>Release Notes<label id="relnotes"> As everyone can clearly see, this document is still in an evolutionary process of extension, and probably ever will be, keeping track of new versions and approaches to encryption for Linux. However, the documentation on the loopback device encryption is mostly complete. Waiting for the network section to grow to the same level would greatly increase the time needed for the first release to publicly appear, leaving the documentation on disk encryption complete but unread by those for whom this document is written---the users. I therefore decided to publish version 0.1.0 on my web page and submit it to the linux HOWTO maintainer, Tim Bynum, letting him decide if he he will include versions below 1.0.0 in the HOWTO index. FreeS/WAN 1.0 does not work properly (i.e. stable) on 2.2 kernels. It is also by far the most complex package to be described here, so please be patient with me on this one. FreeS/WAN 1.1 is out for a few weeks now, but I have not had the time to look at it. Nevertheless rumors are good about it and 1.2 is to come out "between Thanksgiving and Christmas" (1999, that is). Any feedback and contribution is hereby strongly encouraged. Finalizing this document will be much work and I am currently in the process of preparing myself for writing my diploma thesis in mathematical physics, which will take a year or so to complete, hence I cannot spare that much time. Also, I have currently no home network to play with, so testing the network encryption approaches has to be done in the university, which slows things down. If you contact me concerning this document, please include the string "[Encryption-HOWTO]" in the subject of the message. My E-Mail address can be found at the beginning of this document. This is version 0.1.0 of the Linux Encryption HOWTO, which brings the disk encryption part to a publishable form, relying on work done by Doobee. R. Tzeck <htmlurl url="mailto:drt@ailis.de" name="(drt@ailis.de)"> for mostly anything that has not to do with loop device encryption. The planned roadmap for future milestone versions looks thus: Version 0.2.0 will eventually bring the network section to a state similar to the disk section, with a detailed description of CIPE and short summaries of the other approaches. Target date is late Dec 1999. Version 0.3.0 should include a thorough description of Free/SWAN, with v1.0.0 unifying the overall structure and presenting a more or less complete overview of encryption for 2.2 kernels. Target date for 1.0.0 is approximately mid-2000. Quickly following that will be v1.1.0 which will take the whole stuff to kernel v2.4. You can always find the latest version of this document at its homepage at <htmlurl url="http://marc.mutz.com/Encryption-HOWTO/" name="http://marc.mutz.com/Encryption-HOWTO/">.   <sect>Obtaining and Installing the International Kernel Patch <label id="ikp"> The International Kernel Patch is the primary souce for encryption support for the Linux kernel. Due to export restrictions in some countries that prohibit the free flow and exchange of software that contains strong cryptography, it is not possible to include crypto support in the main kernel source tree (i.e. Linus' one). Therefore, you should not consider the packages contained therein unstable or even unusable only because they are not contained in the main kernel. Most of this stuff is actually quite stable and I partly wrote this HOWTO to broaden the base of installed international kernels, so that code development can go on faster. The International Kernel Patches are maintained by <htmlurl url="mailto:astor@fast.no" name="Alexander Kjeldaas"> and can be obtained from <htmlurl url="ftp://ftp.kerneli.org/pub/linux/kerneli/v2.2/" name="ftp://ftp.kerneli.org/pub/linux/kerneli/v2.2/">. The files to download are named <tt>patch-int-a.b.c.d.gz</tt>, where <tt>a.b.c</tt> is the kernel version and <tt>d</tt> is the patch level of the International Kernel Patch for that particular kernel version. I strongly recommend to get at least the 2.2.10.4 version of the patch, as it fixes a problem with moving around files that are used as loopback devices, see <ref id="faq:disk" name="FAQ section">. As of this writing (Nov 1999) 2.2.13.2 is the latest version. It should apply cleanly to all 2.2.1x kernels. The international kernel is distributed in the form of patches. If you are not familiar with this distribution form, you should consult the <htmlurl name="Kernel HOWTO" url="Kernel-HOWTO.html"> for how to apply patches to the kernel source. For the purpose of this document it suffices if you issue the following commands as root: <verb> root# cd /usr/src/linux root# cp .config .. # this is a trick I use root# make mrproper # to avoid the changing of root# mv ../.config . # the .config file by mrproper root# zcat ~/patch-int-a.b.c.d.gz | patch -p1 </verb> assuming that you downloaded the patch to root's home directory. The patch should apply cleanly. <sect>The Crypto API<label id="cryptoAPI"> The Crypto API is an approach to unify the interface between kernel modules using crypto routines (such as the loop_gen driver or CIPE (eventually?)) and kernel modules providing crypto routines (such as cipher or hash modules). It shows up as the ``Crypto Options'' menu in <tt>make menuconfig</tt>. At the time of this writing (Aug 1999), only the crypto loop device driver (<tt>CONFIG_BLK_DEV_LOOP_GEN</tt>) uses this facility and not all ciphers contained in the international kernel have been integrated into the Crypto Library. It is obviously desirable that all kernel modules using strong encryption use the Crypto API (where applicable). To this end, this HOWTO will eventually include a discussion on the ``API of the Crypto API'', so developers trying to use this library are no longer forced to read the source to find the appropriate functions. Developers who want to earn their merits will find here a great opportunity to play. Help to implement new ciphers and hashes and put them under the GPL. Help to convert existing ciphers already contained in the international kernel to use the crypto API. Help to enhance the performance of ciphers by implementing them in native assembler code for different platforms! You don't need to be a kernel hacker to support this project, as the modules involved are rather small and similar to each other. <bf>But please understand that the project cannot accept patches that were written by people being a citizen of or living (temporarily or permanently) in the US, or any country that employs export restrictions on strong cryptography.</bf> Late International Kernel Patches (from 2.2.12.2 on) extend the concept of the Crypto API from plain cipher modules to digest (i.e. cryptographic hash) modules. Currently only MD5 is supported, which was contributed by Alan Smithee.   <sect>Encrypting Disks<label id="disk"> In this section I will show how to configure the kernel and some of its utilities to use the loop device mechanism to encrypt block devices (i.e. partitions or regular files containing whole filesystems). This is the preferred method, as it is fast, simple and reliable. There are, however, some restrictions still not resolved that avoid its use in all and every situation (e.g. swap partitions and root filesystems cannot yet be encrypted reliably), so I will briefly discuss other approaches that may fix some of these issues in section <ref id="disk:other" name="Other Disk Encryption Approaches">. <sect1>Configuring the Kernel<label id="ikp:kernel"> After successfully applying the patch to the kernel source tree, we are in the position to configure the kernel to actually use the encryption routines. As usual, this includes re-compilation of the kernel. If this should be the first time you compile a custom kernel yourself, get yourself the help of a friend or read the <htmlurl name="Kernel HOWTO" url="Kernel-HOWTO.html">. <tt>make oldconfig</tt> will prompt you for only the new kernel options, while <tt>make xconfig</tt> or <tt>make menuconfig</tt> will somewhat hide the new features as they are spread over all the menus, as we will see in a minute. After configuring the options you want (see below), you re-compile and install the kernel as usual and then reboot it. Your kernel has now all it needs to support encryption of disks. <sect2>Overview of kernel options This is a short summary of disk encryption related kernel config options. See section <ref id="net" name="Encrypting Network Traffic"> for options related to network traffic encryption. As of 2.2.11.2, the help texts of most of these options do not contain much information. <descrip> <tag>CONFIG_CIPHERS (Crypto Ciphers):</tag>This enables the use of a wide variety of crypto ciphers (= routines that de/encrypt data) for the Crypto API. The Crypto API can be employed to disk encryption via the generic crypto driver for the loop device (<tt>CONFIG_BLK_DEV_LOOP_GEN</tt>). That obsoletes the concept that the ``direct'' drivers <tt>CONFIG_BLK_DEV_LOOP_CAST</tt> and <tt>CONFIG_BLK_DEV_LOOP_FISH2</tt> are using. Use of the generic driver is strongly recommended. <tag>CONFIG_CIPHER_*:</tag>This set of options enables specific ciphers (= routines that de/encrypt data) to be used in CBC mode by the Crypto API (see above). <tag>CONFIG_BLK_DEV_LOOP (Loopback device support):</tag> This options has nothing to do with encryption per se. However, as the current disk encryption implementation uses the loop device, you must say ``Y'' here. <tag>CONFIG_BLK_DEV_LOOP_USE_REL_BLOCK (Use relative block numbers...):</tag> This options allows you to copy around the file containing your encrypted file system without affecting it's usability. Without this option enabled, you have to make sure it stays at the exact same place on the disk in order to use it, because the (absolute, as opposed to relative) block numbers the file occupies on disk affect the crypto cipher, see the question on copying files in the FAQ section. <tag>CONFIG_BLK_DEV_LOOP_GEN (General encryption support):</tag> This option provides an additional layer of abstraction for crypto ciphers. With this option enabled, you can use any of the ciphers (<tt>CONFIG_CIPHER_*</tt>) the Crypto API supports. <tag>CONFIG_BLK_DEV_LOOP_CAST (CAST128 encryption):</tag> This option provides 128-bit key CAST encryption in ECB mode for use with the loop device. This option does not depend on the general encryption support (<tt>CONFIG_BLK_DEV_LOOP_GEN</tt>) or the Crypto API above. Use of this option is deprecated. <tag>CONFIG_BLK_DEV_LOOP_FISH2 (Twofish encryption):</tag> This option provides Twofish encryption in CBC mode for use with the loop device. This options does not depend on the general encryption support (<tt>CONFIG_BLK_DEV_LOOP_GEN</tt>) or the Crypto API above. Use of this option is deprecated. </descrip> <sect2>Selecting the right options This is easy. First, you choose which cipher you want to use. Make sure that you know what using a particular cipher implies (licensing fees and/or even break of law). The help texts as well as the glossary at the end of this document will help you with that, although these sources are not to be considered authorative. Next, if you want to use CAST-128 or Twofish, then say ``yes'' to <tt>CONFIG_BLK_DEV_LOOP</tt> and <tt>CONFIG_BLK_DEV_LOOP_CAST</tt> or <tt>CONFIG_BLK_DEV_LOOP_FISH2</tt>. Note that the implementation of these ciphers will likely change in future releases, as they will become accessible through the Crypto API. I'm not sure the future implementation will be compatible with existing encryption, so use these only if you have no choice or want to experiment. As of 2.2.11.2 they are broken anyway. If you want to use one of the ciphers in the Crypto API, then you need to say ``yes'' to <tt>CONFIG_CIPHERS</tt>, <tt>CONFIG_BLK_DEV_LOOP</tt>, <tt>CONFIG_BLK_DEV_LOOP_GEN</tt> and the cipher you wish to use under ``Crypto options''. I recommend to also enable <tt>CONFIG_BLK_DEV_LOOP_USE_REL_BLOCKS</tt> (available in <tt>patch-int-2.2.10.4</tt> and later), as this solves problems with physically moving around the encrypted file on disk. <bf>NOTE:</bf> Using relative block numbers will probably not help you if you plan to move the file containing the encrypted filesystem between underlying filesystems with different block sizes. I nearly lost my gigabyte of encrypted data while trying to do so. If you want to compile crypto ciphers as modules, see the FAQ section for how. <sect1>Patching the <tt>util-linux</tt> source<label id="losetup"> After re-compiling the kernel and rebooting it, you need to patch some of its helper programs, namely &losetup; and/or &mount;. The patch used resides in the <tt>Documentation/crypto</tt> hierarchy of the kernel source tree. &losetup; and &mount; need to be patched if you want to use any of the following ciphers: <itemize> <item>Blowfish <item>DFC <item>IDEA <item>MARS <item>RC6 <item>Serpent </itemize> Note that this collection is compiled from my own personal tests and is only valid for <tt>patch-int-2.2.11.2</tt>. As it is one short-term goal to unify the conceptional design of the crypto modules (i.e. all will use the loop_gen abstraction someday), the size of this list is likely to monotonically increase as new releases come out. &mount; used to be modified for the use of some ciphers that do not depend on the generic driver (<tt>CONFIG_BLK_DEV_LOOP_GEN</tt>). These, as all the ciphers not mentioned in the above list, are currently broken in that no userspace tools are available that allow their use. This will be fixed someday (developers?). The DES cipher is likely to be removed, as it is not secure anymore. 3DES (triple DES) will take its place. In order to patch the mount utilities to support encrypted filesystems over the loop device, you need to fetch a recent source tree of the util-linux package, e.g. from <htmlurl url="ftp://ftp.de.kernel.org/pub/linux/utils/util-linux/" name="ftp.de.kernel.org/pub/linux/utils/util-linux/">. As usual, you issue the following commands to apply the patch: <verb> user$ tar xfzv util-linux*.tar.gz user$ cd util-linux* user$ patch -p1 < /usr/src/linux/Documentation/crypto/util-linux*.patch </verb> It should apply cleanly if you use the patch only on util-linux trees that have a higher version number than the patch file shows. Next you have to make sure that only the mount utilities are built. You can get in all sorts of troubles if you mess around with <tt>init</tt> or the password authentication programs. <bf>You can render your computer unusable if you do not make sure that you only compile &mount; and &losetup;!</bf>. In order to avoid this mess, you need to install the executable files yourself, so you can gain control over what is being installed. But that is not hard to do: After paching the util-linux source tree as described above, issue the following commands in the <tt>util-linux*</tt> directory. Make sure you have not currently mounted any filesystems using the loop device. <verb> user$ ./configure user$ make -C lib setproctitle.o # mount depends on this user$ cd mount user$ make losetup mount umount root# for i in losetup mount umount; do root> j=$(locate bin/$i) root> cp $j{,.old} && chattr +i $j.old root> cp $i $j root> done </verb> Change the permissons and ownership of the new binaries according to your distribution's policy (check the old binaries for the right settings). <sect1>Making an Encrypted Folder<label id="folder"> Create a file that will hold the encrypted data. We will call it <tt>.crypto</tt> for now and assume it is placed in the home diretory of user ``user''. You can use any other name, though. Note that this file will not grow dynamically as you feed more and more data into it. On the other hand, it will permanently block the amount of disk space you allocate to it, even if there is no data stored in the encrypted folder. However, you can always grow or shrink the filesystem manually, see FAQ section for how. Choose a reasonable size, e.g. 10M in the following command (calculated as <it>bs * count</it>): <verb> user$ dd if=/dev/urandom of=~/.crypto bs=1024k count=10 </verb> This will take some time, as the urandom device emits random numbers that need to be created first. The above command takes about one minute to complete on my 300 MHz AMD K6-2. You might want to use <tt>/dev/zero</tt> instead, if you have a slow machine or want a huge crypto filesystem, but then your filesystem is said to be vulnerable to known-plaintext attacks. I cannot follow that argument, as we do not encrypt the zeros, but instead pretend they were the ciphertext. However, using zeros to create the file in the first place makes it possible for the attacker to know which blocks have not been written to. This may give him one or another hint as to how to attack your ciphertext. You may also choose to encrypt a whole partition. Just make sure it contains no data and replace the filename <tt>~/.config</tt> in the following discussion with the name of the block device that you wish to use (e.g. <tt>/dev/sda3</tt>). Now set up this file as the target of a loop device. You must do this as superuser, unless the loop device files can be written to by everyone (not recommended). Choose a loop device that is not currently in use. Try <tt>mount|grep loop</tt> to see which loop devices are currently used by &mount;. <verb> root# losetup -e ciphername /dev/loop0 ~user/.crypto Password : </verb> Note that you should take your time as you enter the password, as you are not prompted to enter it again for typo checking! You may even choose to prefix the above command with <tt>echo pass|</tt>, where <tt>pass</tt> is your proposed password, so you can see what you type, but that is deprecated. If you want to do it this way, make sure you switch to maintainance mode first (<tt>init S</tt>), so no-one can sneak your password. What you have done so far is to set up a so-called encrypted block device <tt>/dev/loop0</tt>. It is functionally equivalent to a partition device (e.g. <tt>/dev/hda1</tt>), so you next need to do what you (or your installation tool) did with naked partitions: Make a filesystem on it. Ext2 should be your choice, as it is Linux' native filesystem: <verb> root# mke2fs /dev/loop0 </verb> Next, you mount it. We take the mount point to be <tt>~/crypto</tt> (notice the omission of the leading dot!): <verb> user$ mkdir ~/crypto root# mount -t ext2 /dev/loop0 ~user/crypto </verb> The last step needs to be done as root, as only the superuser is allowed to (un)mount filesystems, unless otherwise stated in &fstab;. If all worked well, you now have a filesystem that encryptedly resides in the file <tt>~/.crypto</tt> and is mounted on <tt>~/crypto</tt>. You can enter it and look at the files in it (not many now as it is just newly created, only the <tt>lost+found</tt> folder should be visible). Now, all this is nice but really clumsy to do everytime you want to access the encrypted data. But before you learn how to make mounting the encrypted file/folder more user-friendly, you first need to unmount and destroy the loop device. I'd like to make it very clear at this point that encryption does not buy you anything if you leave the filesystem mounted all the time and/or set the permissions not restrictive enough. You should be familiar with what the following commands do, so I will let them speak for themselves: <verb> root# grep -q "lost+found" /dev/loop0 && echo 'found!' root# chmod go= ~user/.crypto root# chown user -R ~user/crypto root# chmod go= -R ~user/crypto </verb> Now unmount the filesytem: <verb> root# umount /dev/loop0 </verb> and detach the loop device from the file: <verb> root# losetup -d /dev/loop0 </verb> You next edit your &fstab; to include the following line: <verb> /home/user/.crypto /home/user/crypto ext2 \ defaults,noauto,loop,encryption=ciphername,user 0 0 </verb> where <tt>ciphername</tt> is the same as the one you used with the &losetup; command. This approach has some advantages over the one previously used to initially create the filesystem: <enum> <item>You don't need to be root to (un)mount the filesystem (option <tt>user</tt>; this is not meant to be the example username ``user'' we used throughout this section!) <item>You don't need to call &losetup; yourself, as &mount; will do that for you (options <tt>loop</tt>, <tt>encryption</tt>) <item>You don't need to keep track of already used loop devices, as &mount; will do this for you, choosing free loop devices by itself as needed. </enum> <sect1>Automagically Encrypting the Home Directory with ``EHD'' <label id="home"> I cannot yet discuss this (additional) patch to the util-linux tree, as I have not yet successfully installed it on my system. You may do your own experiments, though: The patch (written by Id Est) and some documentation can be obtained from <htmlurl url="http://members.home.net/id-est/" name="http://members.home.net/id-est/">. Do not expect too much comfort from this patch, however. It does not work with <tt>rsh</tt>, which is OK, because <tt>rsh</tt> is inherently insecure, but also not with <tt>ssh</tt> and <tt>su</tt>, which is not acceptable in a networked environment. Also, I have not seen how it should work for X sessions. All these restrictions stem from the inherent need to enter the passphrase for decryption. Maybe PAM (pluggable authentication) modules are a better place to implement this functionality, but I have yet to see such an approach being taken. <sect1>Other Disk Encryption Approaches<label id="disk:other"> The loop device approach has several drawbacks. Some will be resolved sometime soon, some are deeply buried in the design of the loop device mechanism. Some can be overcome with scripts and tricks, some are not that easy. Major drawbacks---and a good reason for other approaches to exist---include (in order of increasing chance to overcome them): <enum> <item>You are not able to encrypt devices that are used for swap. Trying this will lead to deadlocks when swapping heavily: The kernel tries to free memory by swapping out some areas of memory, the device tries to encrypt the data, encryption requires memory---bingo. <item>You are not able to export directories encryptedly via NFS (loop device over NFS-mounted files doesn't work in current kernels, as far as I know). So you must export directories in the clear. <item>Root filesystem encryption is tricky. <item>(Automated) incremental backups are difficult. <item>Changing password. The hashed passphrase is used as the encryption key, so changing the passphrase changes the key, i.e. you are no longer able to access the encrypted data. </enum> Other disk encryption approaches known to me are: <itemize> <item>PPDD (Personal Privacy Disk Driver) by Allan Latham <htmlurl name="(alatham@flexsys-group.com)" url="mailto:alatham@flexsys-group.com">. It claims to be able to encrypt root and swap devices and be ``fool-proof'' in its usage. I have downloaded, but not yet installed it. Latest version as of this writing (Nov 99) is 1.0, anything below 0.9 is not recommended by the author. There is a mailing list where you can ask questions, just send a message with the single word subscribe in the body of the message to <htmlurl name="ppdd-request@linux01.gwdg.de" url="mailto:ppdd-request@linux01.gwdg.de">. You'll receive a message telling you what to do next. This is what Doobee writes about it in his document (see below for an URL): <quote> You can read more about the design of PPDD in the specification or in the PPDD man page (available at the homepage, see below). One 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 International Kernel Patch without big hassle. Perhaps you get a few rejects while patching the two together, but these are easy to resolve by hand. You can find PPDD at <htmlurl url="http://linux01.gwdg.de/~alatham" name="http://linux01.gwdg.de/~alatham"> and <htmlurl url="ftp://ftp.gwdg.de/pub/linux/misc/ppdd" name="ftp://ftp.gwdg.de/pub/ linux/misc/ppdd">. If you want to know how to install PPDD, check out the file ppddhow.txt. I have done some performance testing on a dual PII/266 MHz/256 MB using <tt>bonnie</tt>. Writing on an encrypted volume takes about twice the time as writing to a plain volume. But reading from an encrypted volume takes 4 times as long as reading from an unencrypted one: <verb> -------Sequential Output-------- ---Sequential Input-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU plain 100 4022 95.0 13628 28.7 4036 17.8 3782 84.7 11663 20.4 encrypted 100 2609 75.5 5719 17.2 808 23.8 968 44.9 1165 28.1 --Random-- -----Time------ --Seeks--- -user- -system- Machine MB /sec %CPU sec sec plain 100 286.3 7.0 42.98 13.82 encrypted 100 18.2 5.1 43.40 103.28 </verb> While doing these tests my PS/2 mouse reacted like I was using Windows :-( but this should be tweakable by skewing with the buffer cache. </quote> </itemize> The rest of this section is copied with kind permission of the author from Doobee. R. Tzeck's <htmlurl url="mailto:drt@ailis.de" name="(drt@ailis.de)"> document "Encrypting your Disks with Linux" at <htmlurl url="http://drt.ailis.de/crypto/linux-disk.html" name="http://drt.ailis.de/crypto/linux-disk.html">. <itemize> <item>CFS (Cryptographic Filesystem) 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 <htmlurl url="cfs-linux-HOWTO.html" name="Cryptographic File System under Linux HOWTO"> or "A Cryptographic File System for Unix" by Matt Blaze at <htmlurl url="ftp://research.att.com/dist/mab/" name="ftp://research.att.com/dist/mab/">. CFS supports DES, which is insecure because the key is too short, 3DES, which can be considered secure but painfully slow, MacGuffin, which is broken, and SAFER-SK128, which has an unusual design and is designed by some NSA buddys at Cylink---enough reason to not fully trust this algorithm. But <htmlurl url="mailto:darkstar@frop.org" name="darkstar@frop.org"> was kind enough to hack Blowfish into CFS and Matt Blaze integrated it into CFS 1.3.4. The main problem of CFS even with Blowfish is the lack of speed. This results from 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. <itemize> <item><url url="http://drt.ailis.de/crypto/cfs-1.3.3.tar.gz" name="cfs source code"> <item><url url="http://drt.ailis.de/crypto/cfs-1.3.3bf.1.tar.gz" name="cfs with blowfish source code and bf_tab.h"> </itemize> <item>TCFS (Transparent CFS) which is being developed at the University of Salerno, Italy, claims to improve Matt Blaze's CFS by providing deeper integration between the encryption service and the filesystem, 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. One big misfeature of TCFS is the fact that it needs kernel patches and that the patches are still made for the now obsolete 2.0 kernels. 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 that is next to nothing, using only the login password to decrypt the key. To learn more about TCFS, read the TCFS-FAQ at <htmlurl url="http://tcfs.dia.unisa.it/tcfs-faq.html" name="http://tcfs.dia.unisa.it/tcfs-faq.html">. Since it is from Italy, which is part of the free world, you can download it without any problems, from the TCFS Homepage at <htmlurl url="http://tcfs.dia.unisa.it/" name="http://tcfs.dia.unisa.it/">. <item>SFS (Steganographic File System) The theoretical background of SFS was laid by Ross Anderson, Roger Needham and Adi Shamir in their paper "The Steganographic File System". You can grab it at <htmlurl url="http://drt.ailis.de/crypto/sfs3.ps.gz" name="http://drt.ailis.de/crypto/sfs3.ps.gz">. 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: <quote> 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. </quote> They had a homepage at <htmlurl url="http://leg.uct.ac.za/~carl/vs3fs/" name="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 <htmlurl url="mailto:peter@schneider-kamp.de" name="(peter@schneider-kamp.de)"> updated the stuff to 2.2. This stuff can be found at <htmlurl url="http://www.linux-security.org/sfs/" name="http://www.linux-security.org/sfs/">. But since his pages seem to be down, too, you can also get it at <htmlurl url="http://drt.ailis.de/crypto/sfspatch-2.2.10.tar.gz" name="http://drt.ailis.de/crypto/sfspatch-2.2.10.tar.gz">. SFS still has a lot of rough edges and Peter doesn't seem to maintain it actively. <item>StegFS (Steganographic File System) 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 seems reasonable. StegFS seems to be really elaborate and looks much more usable to me than SFS. Since McDonald and Kuhn come from the same University as Anderson, it seems obvious that they tried hard to meet the criteria of the Steganographic Filesystem paper. StegFS has a homepage at <htmlurl url="http://ban.joh.cam.ac.uk/~adm36/StegFS/" name="http://ban.joh.cam.ac.uk/~adm36/StegFS/">. <item>CryptFS There is another good-looking crypto file system called CryptFS. It is described in <url url="http://www.cs.columbia.edu/~ezk/research/cryptfs/index.html" name='"CryptFS: A Stackable Vnode Level Encryption File System"'> and can be downloaded from <htmlurl url="http://www.cs.columbia.edu/~ezk/research/software/cryptfs/" name="http://www.cs.columbia.edu/~ezk/research/software/cryptfs/">. But since this site is in the USA, which is a country keeping its scientists from publishing research worldwide, CryptFS is unusable for people from the free world until some dark figure smuggles it over here. <item>BestCrypt and Virtual Private Disk As they are commercial products, I (Marc Mutz) will not include a discussion of them here. </itemize>   <sect>Encrypting Network Traffic<label id="net"> This section is in preparation. See the section <ref id="relnotes" name="Release Notes"> for a planned roadmap. I will just give you the necessary links to find other documentation on the following packages: <itemize> <item>CIPE (Cryptographic IP Encapsulation) by Olaf Titz (<htmlurl url="mailto:Olaf.Titz@inka.de" name="Olaf.Titz@inka.de">) ships with the International Kernel Patch (see section <ref id="ikp" name="Obtaining and Installing the International Kernel Patch">)---at least the kernel modules. The userspace tools needed are available from <htmlurl url="http://sites.inka.de/~bigred/devel/cipe.html" name="http: //sites.inka.de/~bigred/devel/cipe.html">. Latest version is 1.3.0 (Apr 1999). There is also a mailing list dedicated to CIPE. You can subscribe to it by sending a message with the single line subscribe cipe-l in its body to <htmlurl url="mailto:majordomo@inka.de" name="majordomo@inka.de">. <item>FreeS/WAN (IPSec implementation) is available at <htmlurl url="http://www.freeswan.org" name="www.freeswan.org">. Current version is 1.1 (Oct 1999), which is reported to work well with 2.2 kernels (1.0 does not). FreeS/WAN is a Linux based implementation of the IETF IPSec standard. If you want to know all there is to know about IPSec, see the RFC's concerned with it, esp. the famous RFC's 2401: Security Architecture for the Internet Protocol thru 2412: The OAKLEY Key Determination Protocol. Note, however, that these documents add up to 20,000 lines of pure text or 800K. This package is very complex indeed, but as it is based on an IETF standard, it inter-operates with many other (commercial) VPN products, including PGPnet. This makes it the single obvious choice for admins that need extensive cross-platform capabilities. There is a very active mailing list you can subscribe to, if you send a message with the single line subscribe linux-ipsec in the body of the message to <htmlurl url="mailto:majordomo@clinet.fi" name="majordomo@clinet.fi">. <item>ENSkip is an implementation of Sun's SKIP protocol. Its advantages over other approaches include a long history, which implies a relative stableness, and good cross-platform capabilities (at least within the Unices department). You can find its homepage at <htmlurl url="http://www.tik.ee.ethz.ch/~skip/" name="http://www.tik.ee.ethz.ch/~skip/"> <item>VPND is another approach out there for Linux (and FreeBSD). You can fetch additional information from its homepage at <htmlurl url="http://sunsite.auc.dk/vpnd/" name="http://sunsite.auc.dk/vpnd/">. There is also a mailing list, which you can subscribe to if you send an empty message to <htmlurl url="mailto:vpnd-subscribe@sunsite.auc.dk" name="vpnd-subscribe@sunsite.auc.dk"> and follow the directions given in the reply. <item>SSH (Secure Shell) can also be employed to establish an encrypted tunnel between two hosts. There is a VPN mini-HOWTO already covering the setup, but it is rather dated (Aug 1997). </itemize>   <sect>Frequently Asked Questions<label id="faq"> <sect1>Disk Encryption<label id="faq:disk"> <sect2>General Questions<label id="faq:disk:gen"> <enum> <item><bf>How can I encrypt swap?</bf> With the loop device approach, you cannot. PPDD claims you can. I don't know about (T)CFS. See the sections on individual approaches below. </enum> <sect2>Loop Device Encryption<label id="faq:loop"> <enum> <item><bf>Can I use all this as modules?</bf> ( <htmlurl name="AK" url="mailto:astor@fast.no"> ) Sure! In <tt>make menuconfig</tt> (or whatever), under ``Crypto options'', say M to ``Crypto ciphers (<tt>CONFIG_CIPHERS</tt>)'' and to the ciphers you want. Under ``Block Device'', say M to ``loopback device (<tt>CONFIG_BLK_DEV_LOOP</tt>)'' and to ``General Encryption Support (<tt>CONFIG_BLK_DEV_LOOP_GEN</tt>)''. Don't select any other encryption modules unless you can't live without them and they are no longer supported by the Crypto API. Build your kernel and modules, <tt>make modules_install</tt>, reboot, <tt>depmod -a</tt>. In <tt>/etc/conf.modules</tt>, add: <verb> alias loop-xfer-gen-0 loop_gen alias loop-xfer-gen-10 loop_gen alias cipher-4 blowfish # Blowfish alias cipher-6 idea # IDEA alias cipher-7 serp6f # Serpent alias cipher-8 mars6 # MARS alias cipher-11 rc62 # RC6 alias cipher-15 dfc2 # DFC </verb> <item><bf>Why all those funny numbers?</bf> ( <htmlurl name="AK" url="mailto:astor@fast.no"> ) In short, the kernel knows ciphers only by number. If you really want to know how it works, you can <tt>grep request_module</tt> in <tt>linux/crypto/api.c</tt> and <tt>linux/drivers/block/loop.c</tt>. ( me ) If the cipher you wish to use is not in the above list, then see the file <tt>include/linux/crypto.h</tt> in the kernel source tree. There you'll find the defines for all cipher numbers. See the directory <tt>crypto</tt> in the kernel tree for the (file)name of the module that implements the cipher. <item><bf>How do I change the password / the cipher?</bf> You can't. At least not easily. Well, you can, but you won't be able to access your data anymore. Seriously: The passphrase is hashed and then used as the encryption key. You cannot change the password and expect the hash value (ie. the encryption key) to stay the same. What you can do, however, is the following. Make sure, you have not currently set up or even mounted the filesystem you want to change. In the notation of section <ref id="folder" name="Making an Encrypted Folder"> you then issue: <verb> root# losetup -e oldcipher /dev/loop0 ~user/.crypto Password : (old one) root# losetup -e newcipher /dev/loop1 ~user/.crypto Password : (new one) root# dd if=/dev/loop0 of=/dev/loop1 bs=1k conv=notrunc root# losetup -d /dev/loop0 root# losetup -d /dev/loop1 </verb> If you changed the cipher, you will need to change the entry in &fstab; accordingly. If you plan to do this often (and maybe you should do that), it pays to write a script for it that prompts you twice for the new password. If you are really lucky, then I will have written this for you already :-). <item><bf>My encrypted filesystem is (nearly) full. How do I enlarge it?</bf> If you have enough free space left so that you can create the new-size file without having to remove the old first, then the solution is obvious: <itemize> <item>Mount the old filesystem, e.g. on <tt>crypto</tt>. <item>Setup and mount a new filesystem as described in section <ref id="folder" name="Making an Encrypted Folder">, e.g. on <tt>newcrypto</tt>. <item>Copy the files thus: <verb> user$ tar cf - -C crypto . | tar xf - -C newcrypto </verb> </itemize> <item><bf>But I do not have that much free space left! Is there still hope?</bf> Yes: <tt><url name="ext2resize" url="http://www.dsv.nl/~buytenh/ext2resize/"></tt>. It is, as the name suggests, a tool that allows you to grow or shrink ext2 filesystems. And that seems to be exactly what we'll need. Basically, what you have to do is: <itemize> <item>Enlarge the file wherein the filesystem is contained by e.g. 10M: <verb> user$ dd if=/dev/urandom bs=1024k count=10 >> ~/.crypto </verb> <item>Set up the loop device and check the filesystem: <verb> root# losetup -e cipher /dev/loop0 ~user/.crypto Password : root# e2fsck /dev/loop0 e2fsck 1.12, 9-Jul-98 for EXT2 FS 0.5b, 95/08/09 /dev/loop0: clean, 11/1920 files, 506/10240 blocks </verb> <item>Resize the filesystem. The second parameter to <tt>ext2resize</tt> is the new size in blocks. In our example: <it>10240 + 10M/1k = 20480</it> <verb> root# ext2resize /dev/loop0 20480 </verb> <item>Now detach the loop device again: <verb> root# losetup -d /dev/loop0 </verb> </itemize> You have now an enlarged filesystem. Note, however, that power failure or the like can easily destroy your data while resizing is running! There is a patch floating around that will let you do this with a mounted filesystem. With this solution, however, you have to unmount the filesystem before resizing. <item><bf>Can I encrypt my swap partition? Can I page to a swapfile that's on an encrypted filesystem?</bf> No, not yet. First, some issues with memory allocations in the driver have to be resolved. <item><bf>Cipher xyz does not work. It says ``unsupported cipher xyz'' / ``ioctl: LOOP_SET_STATUS: Invalid argument'' although I have compiled it into the kernel.</bf> Not for all ciphers does a user-space setup tool currently exist. Please see section <ref id="losetup" name="Patching the util-linux source"> for a list of working ciphers or try them all in turn. <item><bf>I copied the file containing the crypto filesystem to another directory / I defragged my partitions and now I cannot access my data any more.</bf> Most probably you have compiled the kernel without <tt>CONFIG_BLK_LOOP_DEV_USE_REL_BLOCK</tt>. As the copy now occupies different blocks on the filesystem and you are not using relative block numbers, the ciphers get it wrong. The only thing that will help you now is the <tt><url name="ext2recover" url="http://www.iki.fi/markus.stenberg/ext2recover.html"></tt> tool by Markus Stenberg (<htmlurl url="mailto:markus.stenberg@abacus-solutions.com" name="markus.stenberg@abacus-solutions.com">). It will recover your data except the first four bytes of every block. If your lost data was only text files, that should be enough. If it was binary data it will most probably not be enough. <item><bf>I use an older 2.2 kernel. How do I avoid the above mess?</bf> You can use the ``double loop trick'': <verb> root# losetup /dev/loop0 crypto root# losetup -e ciphername /dev/loop1 /dev/loop0 </verb> This will create a new block device <tt>/dev/loop0</tt>, where it is guaranteed that blocks are sequentially numbered starting with zero. That's the same as using relative block numbers on <tt>crypto</tt> directly. If you create your crypto loop device this way, you can be sure it will still work after defrag etc. Note that <tt>mount</tt> does currently not support this trick, so you will have to set up your loop devices by hand. All in all, you should really update to a newer kernel :-) <item><bf>How do I make backups?</bf> You can't (at least not easily) when you equal "backup" with "incremental backup". If you can sleep well with image backups instead, and if you used relative block numbers for your loop device (see questions above), you can copy your file containing the crypto filesystem to wherever you want. This includes DAT tapes and removable media, as well as CDR(W). You may want to use tricks like the ones presented above to change the cipher and/or passphrase to use another password for the backup file, dedicated to backups. That is because you have a better chance to remember one of the passwords if the other one gets lost. Also, if you change your password regularly, then how do you remember the password you used two months ago? However, if you do not use relative block numbers, then you cannot easily copy your file around for backups. You can mount the filesystem and have it backed up as plaintext or on another encrypted device. But that will undermine your encryption thoroughly. You'll have to do something along the following lines instead: <verb> root# losetup -e cipher /dev/loop0 ~user/.crypto root# losetup /dev/loop1 ~user/crypto-backup root# losetup -e cipher /dev/loop2 /dev/loop1 root# dd if=/dev/loop0 of=/dev/loop2 bs=1k root# for i in 2 1 0; do losetup -d /dev/loop$i; done root# cp ~user/crypto-backup /backup-media </verb> This will make <tt>crypto-backup</tt> immune to copies (see questions further above for why). <tt>crypto-backup</tt> needs to be at least the same size as <tt>.crypto</tt>, of course. </enum>    </article>