************** Introduction **************** Feedback and criticism about this is needed !! For compliments (or insults) write to Encrypting files on the HDD is surely a good idea. In fact someone could stole your HDD and read all your documents, or simply you could leave an open console by mistake and someone else could use it ... The International Kernel Patch is the standard solution to these issues, but the idea of a kernel patch stresses me out... Moreover, the darned loop file system has a huge limitation: when it is full you need to build another one, because it is not possible to expand the last one (AFAIK). So, walking on, few days ago I came across "umpf" by Vecna (www.s0ftpj.org). I compiled, installed and ... WOW !! The idea of redirecting read() and write() in user space is very interesting. During my tests, I realized that umpf is not perfect, because it dynamically opens a library, while some binaries are statically linked. To solve this problem we need to go to kernel space but without a patch, otherwise the International Kernel Patch is surely better than my garbage. So I thought to myself: go with modules !!! Now, as the great Twiz can confirm, I don't know anything about the Linux Kernel; so, on a Sunday in the mountains, with thousands of guides and tutorials, I dedicated myself to reading and learning: about a month later I gave birth to this tool that, at least on my machine, works. The tool is named "kumpf" (k as "k"ernel; I don't know what "umpf" is for, ask Vecna :P) and it does what umpf does in user space : redirects sys_read() and sys_write() to two new functions that decide whether the file should be encrypted (using the famous sticky bit) and behave the right way. ************** Installation *************** I tested the software with kernel 2.4.19 only. It should probably work with all of the 2.4.x kernel family. Please let me know if otherwise! 1) Be sure the link /usr/src/linux points to the right kernel source 1bis) if you want, edit the Makefile and uncomment the line to enable the encryption files for root; by default it's commented because I fear encrypting some of the files needed at boot time before setting a password ... A friend of mine once tarred the libc library to test the tar program. Genius! ... (Riccardone is the cleverest :) 2) make 3) (as root) make install 4) (optional, I hope you don't) make uninstall Now you have a new directory within the modules tree named kumpf/; inside you will find: kumpf.o: the core; kumpf_sha1.o: exports the hash sha1; kumpf_blowfish.o: blowfish algorithm; kumpf_dummy.o: an example for dummies (see later) Ok, now 'modprobe kumpf_blowfish.o' and enjoy ! ************** Use ***************** Since I wasn't satisfied with the amount of garbage produced, I also wrote two scripts that are needed to set the password and to encrypt existing files : the source for the scripts is worse than modules one, so do not abuse me too much.. ... In time I will improve them (I'm better at scripting than kernel programming). So, the scripts are under /usr/local/bin. This is an example of the usage: antigua@Hari:~/test$ kumpfpass Password: Again: antigua@Hari:~/test$ echo "luglio col bene che ti voglio" > file antigua@Hari:~/test$ ls -l total 4 -rw------- 1 antigua users 30 Apr 10 23:08 file antigua@Hari:~/test$ kumpfize file file_encrypted antigua@Hari:~/test$ ls -l total 8 -rw------- 1 antigua users 30 Apr 10 23:08 file -rw------T 1 antigua users 30 Apr 10 23:08 file_encrypted antigua@Hari:~/test$ cat file_encrypted luglio col bene che ti voglio antigua@Hari:~/test$ su -c "cat file_encrypted" Password: "zy'~;>t6o'e`]?? jh "k0RG~s(u??Qantigua@Hari:~/test$ Voila'. To remove the original file I suggest you use tools like the good old "wipe". Passwords remain valid for about 30 minutes after being idle, where "idle" means you are not using the encryption part of kumpf... Normal read() and write() are not relevant. To list the available algorithms, read the /proc/kumpf/settings file. The following are 2 known problems : 1) kumpf does not seem to work well with vi/vim and probably other editors. The reason is straightforward: when a file is edited (and saved ) with vi this is what happens (strace output): rename("file_encrypted", "file_encrypted~") = 0 fsync(4) = 0 open("file_encrypted", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3 write(3, "luglio col bene che ti voglio\nci"..., 39) = 39 close(3) = 0 chmod("file_encrypted", 0101600) = 0 ... various stuff ... unlink("file_encrypted~") = 0 that is, when 'vi' writes to the file, the file is not sticky and later it is set to +t. Obviously kumpf does not intercept normal writes, but later, using 'cat', it reads a sticky file... So the file should be manually reset to -t or else you can't read anything ... 2) If you rmmod kumpf, the kernel won't be happy about it... this happens because some of the processes are still using the kumpf read() and write() in a blocking way, and thus there could be a segfault in some of the processes. I never had serious problems with it , but it is actually an issue. A possible solution could be to reset sys_read() and sys_write() to the original values and wait for all the processes to use the original syscalls before exiting (hanging rmmod for an indefinite time)? Suggestions in this area are appreciated. ************** Algorithm ***************** Algorithm is a blowfish in counter-mode and works like a stream cipher: key = hash(password) msg_id = hash(inode->i_ino) K1 = encrypt(key=key,plaintext= (msg_id^1) ) K2 = encrypt(key=key,plaintext= (msg_id^2) ) ... K1|K2|....|Kn is the key stream where | is the concatenation operator. hash() is sha1(). msg_id can be public (actually it is) The only security-related problem I've noted so far is that if I (cracker) save (in time t=t0) an encrypted file and the inode number, and later on (t=t1) another file that has the same inode, recycled by the kernel, the 2 files will have the same key stream and it is possible to make the infamous 'one time pads' attack. This problem, in my own opinion, is not as bad as it seems: in fact, if the cracker reads the inode number, probably he has root privileges anyway and could directly install a module that reads the password. Obviously, if the file is world readable, you can put it directly on your web site... It's simpler :) Most of the blowfish and sha1 code comes from International Kernel Patch (www.kerneli.org) ************** New algorithms ************* Question: I don't like your algorithm! Answer : Write your own one! Kumpf has a totally modular design and it's simple plug in another encryption mechanism. kumpf_dummy.c file is an example for such a mechanism. Just write a module that encrypts/decrypts a buffer and registers itself like in kumpf_dummy.c; The new mechanism is then available like the blowfish one. ************** FAQ ************************* Q: Why did you write this garbage rather than getting drunk? A: Good question ... ************** Thanks ********************** Vecna for idea, Twiz for the lectures on IRC, Riccardone for the psychological support and for translating this file, Cedar^S1 for debugging Riccardone's english, Alessandro Rubini for the "Linux Device Drivers" book, and the rest of the world.