"Fossies" - the Fresh Open Source Software Archive
Member "cryptofs-0.6.0/doc/README.xml" (3 Feb 2007, 9785 Bytes) of package /linux/misc/old/cryptofs-0.6.0.tar.gz:
As a special service "Fossies" has tried to format the requested source page into HTML format using (guessed) XML source code syntax highlighting (style: standard
) with prefixed line numbers.
Alternatively you can here view
the uninterpreted source code file.
1 <?xml version="1.0" encoding="iso-8859-15"?>
2 <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN">
16 <holder>Christoph Hohmann</holder>
20 <title>What's CryptoFS</title>
22 CryptoFS is a encrypted filesystem for Filesystem in Userspace
23 (FUSE) and the Linux Userland FileSystem (LUFS). Visit <ulink
25 for more information on FUSE or <ulink
27 for more information on LUFS.
30 CryptoFS will use a normal directory to store files encrypted.
31 The mountpoint will contain the decrypted files. Every file
32 stored in this mountpoint will be written encrypted (data
33 and filename) to the directory that was mounted. If you
34 unmount the directory the encrypted data can only be access
35 by mounting the directory with the correct key again. Like
36 other FUSE/LUFS filesystems it does not need root access
37 or any complicated setup like creating a filesystem on a
38 encrypted disk using the loop device.
41 CryptoFS can be build for FUSE and LUFS. When you build for
42 FUSE you get a program to mount the filesystem. For LUFS a
43 shared library will be built that can be used by LUFS's lufsd.
44 Both methods can use the same encrypted directory.
49 <title>Why CryptoFS?</title>
51 I first used the evfs kernel patch that does nearly the same thing
52 as CryptoFS. But it seems that it has been abandoned. The last patch
53 was available for kernel 2.4.20 and has not been updated for newer
54 kernels since then. When I found LUFS I thought I could be a good
55 base for a crypto filesystem that works like evfs and allows a user
56 to mount any directory as an encrypted storage without having root
57 access and creating a crypto filesystem using the loop device. So
58 when I found no other program that offers this posibilities I started
59 to write my own filesystem for LUFS. Unfortunately LUFS seems to be
60 dead too, so CryptoFS can now be build for FUSE too which has already
61 made it into the official Linux kernel package.
68 You either need FUSE or LUFS to use CryptoFS.
69 For FUSE you need the FUSE tools, library and
70 kernel module. You also need the FUSE development
71 files to build the FUSE filesystem. See <ulink
73 for more information and downloads. If you don't want to build
74 CryptoFS for FUSE you can use the --disable-fuse configure
75 switch. Otherwise it will be build when the development files
76 are found on the system. For LUFS you only have to install
77 the LUFS tools and load the LUFS kernel module. See <ulink
79 on how to do this and downloads for LUFS. If you want
80 to disable building CryptoFS for LUFS you can use the
81 --disable-lufs configure switch. As the LUFS module has no
82 requirements it will be build by default. Installing and
83 setting up LUFS and FUSE will not be covered by this document.
86 CryptoFS uses Libgcrypt from <ulink
88 (version >= 1.1.44) and GLib from <ulink
90 (version >= 2.6). You must have installed these packages
91 correctly before running CryptoFS's "configure" script.
94 Optionally CryptoFS can use the <ulink
95 url="ftp://ftp.gnupg.org/gcrypt/pinentry/">PIN Entry</ulink>
96 utility by <ulink url="http://www.gnupg.org/">GnuPG</ulink>
97 to ask the user for the filesystem's password. If the pinentry
98 program is found on the system CryptoFS will be automatically
99 built with PIN Entry support. Otherwise it will fall back
100 to the old console input method.
107 First you have to set up the source directory by copying
108 the file cryptofs.conf to <source>/.cryptofs. Where
109 <source> is the directory where you want to store
110 the encryted files. You can adjust the values in the file,
111 but the default should work fine.
114 For FUSE you have to run cryptofs that should be in an executeable
115 path after "make install". The required options are
116 <programlisting><![CDATA[ cryptofs --root=<source> <dest> ]]></programlisting>
117 <dest> is the directory where the filesystem containing
118 the decrypted files will be mounted.
121 For LUFS put the shared library into a directory where the system linker can find
122 it (this will usually be done by "make install") or add the directory
123 to the search path by setting the LD_LIBRARY_PATH environment varibale.
126 After that you can mount the source directory with
127 <programlisting><![CDATA[ lufsmount cryptofs://<source> <dest> ]]></programlisting>
130 You will be asked for the password you want to use for this filesystem. It
131 will be used to generate the cipher key.
134 After that you should be able to use the <dest> directory like any other
135 directory, but all data will be read and written to the <source> directory
136 in an encrypted form.
141 <title>How does it work?</title>
143 <title>The .cryptofs config file</title>
145 The CryptoFS config file in each encryted directory contains 4 options.
146 These are
152 The cipher algorithm used to encrypt files and filenames.
153 This has to be a cipher name known by libgcrypt.
161 The message digest algorithm used to generate the cipher
162 key. This has to be a message digest name known by
171 An encrypted file can not be randomly accessed like a normal
172 file and CryptoFS always reads and writes blocks of this size.
180 This is the number of subkeys CryptoFS will generate to
181 encrypt blocks.
186 <emphasis>NOTE:</emphasis> Before 0.4.0 CryptoFS used a different config file format.
187 The LUFS module can still read this format. The FUSE program only supports
188 the new format. If you want to switch from LUFS to FUSE you have to
189 replace .cryptofs with a file in the new format.
195 When a filesystem is mounted CryptoFS first generates a key for the
196 requested cipher algorithm (cipher option) using the message
197 digest function (md option). Every algorithm has a specific key size
198 and every message digest function has a specific length of the
199 generated message digest. If the message digest size is smaller then
200 the keysize the message digest will be repeated until the key size
201 is reached.
204 After they primary key has been generated n (= salts option= subkeys
205 (initialization vectors) will be generated by encrypting 0 bytes with
206 a 0 initialization vector. These will later be used to encrypt blocks
207 with different subkeys to make sure the cipher text will first repeat
208 after (salts * blocksize) bytes (If the same data is encrypted).
211 When files or links are created or renamed the name will be encoded
212 with the selected cipher, the primary key and the first subkey.
213 The result will then be encoded using a modified Base64 algorithm
214 because the encrypted filename could contain characters that are not
215 allowed by the target filesystem. (The original Base64 algorithm
216 uses '/' for encoding. This is the directory delimiter so it was
217 replaced by '_')
220 When files are written the data will be encrypted. CryptoFS always
221 has to write full blocks. So if only a part of a block should be
222 written the original block will first be read, decrypted, the part
223 replaced and then the result then written encrypted back to disk.
224 To keep this performant that block size must not be too large.
225 But to make sure the cipher text does not repeat to early, CryptoFS
226 uses salts to encrypt blocks. Every block will be encoded with
227 the (blocknumber module salts)th salt. (NOTE: Linux always reads
228 or writes "pages" of size 4096 bytes, these writes will be
229 forwarded by lufsd to CryptoFS. So if you use a blocksize of
230 4096 bytes reading the old block before writing can be omitted
231 and writing should be faster)