Lars Bungum wrote: > What I am talking about is encrypting the root partition with loop-aes, > patching a kernel with loop-aes and replacing the utils necessary for > mounting them, like described in Christophe Devine's HOWTO > (http://howtos.linuxbroker.com/howtoreader.shtml?file=Encrypted-Root-Filesystem-HOWTO.html) > as a starting point. In the future, I would also like to add a gpg > layer, like the one described in the loop-aes.README. Go with multi-key setup that is described in loop-AES' README. Old single-key mode has exploitable weaknesses and should be avoided. > Journalling file systems. Will it be safe to run journalling file > systems, or does one risk loss of data if the power is switched off, > etc, on an encrypted file system? Is there a recommended filesystem at > all, or is the question itself irrelevant for such encryption? Can > write cache be used? Device backed (partition backed) loops are ok with journaling file systems at least when used with loop-AES. Mainline (current -bk version) loop+cryptoloop combo is no longer journaling file system safe. > Changing of passwords. If one has a system of gpg keys and with > passwords contained in USB-dongles, one would like to enforce some > regime of password changing requirements on it. It seems that just > checking the file dates vs. the hw clock would not be good enough, as it > can easily be changed, another thing I have thought of is having a > system with a counter stored on the dongle. It might look like a using > a dongle with a trusted clock is the best option, but I'm hoping to find > out if this can be done through gpg directly or other smart ways. At least current version of loop-AES' mount does not support that. You have to write your own scripts to do that. Depending how gpg encrypted key file was set up, changing password is either re-encrypting key-file contents with new password or changing gpg secret key password. > Performance. I would like to see some benchmarking of the performance > cost of an encrypted filesystem, so that I would know what to expect > from the hardware. Is there any source out there for this? In time the > system will be used for operation on very large files. Here is benhmark I ran some time ago on my 300 MHz Pentium-2 test box. ATA hard disk. Tests file reads and writes to ext2 file system partition. KERNEL IMPLEMENTATION MODE WRITE MiB/s READ MiB/s 2.6.1 cryptoloop single-key 5.21 4.08 2.6.1 loop-AES single-key 9.52 7.56 2.6.1 loop-AES multi-key(MD5 IV) 7.67 6.35 2.4.22aa1 loop-AES single-key 10.55 10.16 2.4.22aa1 loop-AES multi-key(MD5 IV) 8.75 8.13 > Suspend. I read this in the announcement of the loop-AES-v2.0f > file/swap crypto package: > > --- > - Updated loop code to be compatible with Pavel Machek's software > suspend code (2.4 and 2.6 kernels). > --- > > ..but I didn't really understand if this means that it is "recommended" > or safe to use an encrypted version of software suspend now, or if this > is still hazardous. I saw some notes of scepticism among linux kernel > developers. Here compatible means that unencrypted loop devices do not livelock during suspend to disk. If there are encrypted loops active when suspending to disk, encryption keys will get written to disk when kernel RAM is saved to suspend partition, therefore completely voiding security of those keys. -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
