On Sat, Jul 19, 2008 at 05:04:44PM +0100, Jonathan Thornburg wrote: > My laptop (Thinkpad T41p) and I are going to be doing a lot of > travelling in the next year, so I'm investigating how to > (cryptographically) improve my security in case of loss/theft/seizure. > Right now I use cfs (ports) for a few "sensitive" subdirectories, but > 95+% of my /home is still cleartext to anyone with physical access to > the laptop. The same applies for my external backup disks. > > I'm considering putting all of /home under svnd encryption > (still keeping cfs on top for "sensitive" subdirectories), and I have > some questions (see below). I have RTFMs svnd(4), vnconfig(8), and > mount_vnd(8), and googled my way to some useful web pages, notably > http://www.xs4all.nl/~hanb/documents/OpenBSDEncryptedFilesystemHOWTO.html > http://mareichelt.de/pub/notmine/linuxbsd-comparison.html > http://geektechnique.org/projectlab/797/openbsd-encrypted-nas-howto > (Some of these web pages seem to be a bit old, (eg) complaining about > the now-fixed dictionary-attack vulnerability). > > As I understand it, the basic procedure for using svnd is this (starting > with a brand-new-from-the-computer-store disk sd0, and with steps numbered > for later reference: > [1] # fdisk sd0 ... create single msdos-partition > [2] # disklabel sd0 ... create single openbsd-partition "a" > [3] # newfs /dev/sd0a
use ffs2 and 64k blocks > [4] # mount -o softdep /dev/sd0a /mnt > [5] # dd if=/dev/arandom bs=1m of=/mnt/imagefile count=... prepare to wait a few days... there is known plaintext at specific locations anyway, disklabel, filesystem metadata,... It's not really worth it imho > [6] # vnconfig -vck -K 100000 -S /var/saltfile svnd0 /mnt/imagefile > [7] # disklabel svnd0 ... create encrypted openbsd-partition "a" > [8] # newfs /dev/svnd0a make this ffs2 as well, it will speed up fsck a lot, also bump blocksize if you have lots of large files or couldn't care less if you're going to waste a few megabytes... > [9] # mount -o rw,nodev,nosuid,softdep -t vnd /dev/svnd0a /home > > Now my questions: > 1. Are there other Fine Manuals (relevant to svnd) I should Read > besides the ones I listed above? > 2. Where (besides the source code) can I find the svnd encryption > algorithm documented? This would help me research the answer to > the next question... > 3. What are the error propagation properties of the svnd encryption? > That is, for example, if a disk/USB/memory error corrupts a single > 512-byte block in the middle of /dev/sd0a, will that show up as > 512 bytes of corruption in /dev/svnd0c, or will the entire > /dev/svnd0c be corrupted from that point onwards? Afaik it uses blowfish in CBC mode, so you're fscked... Otoh modern disks make quite some noise before they start running out of spare blocks. Backups are a must, crypto or not. (That said, i've never managed to really fry a svnd disk) > 4. Is there any upper size limit to the size of an encrypted image > apart from the kernel 8TB limit and fsck time and memory usage? > For example, is there any problem with using the above on (say) a > 250GB disk? No problem, for the paranoid however you might want to read up on the birthday paradox ;) > 5. Is there any problem with using softdep in steps [4] and [9]? > 6. Are there any special newfs parameters needed for either the underlying > filesystem (step [3]) or the encrypted one (step [8])? The underlying > filesystem will only hold a single huge 'imagefile', whose size won't > change after initial creation (step [5]), so I could imagine saving > a bit of disk space by configuring very few inodes. What about the > FFS/FFS2 minimum free space threshold (newfs -m) -- with the imagefile > preallocated (step [5]), is there any benefit to a nonzero minimum > free space threshold? -m 0 -o time or whatever it is doesn't hurt. > 7. How worried should I be about bug kernel/5709 "rapidly creating many > small files on crypted svnd locks box", which as of a few minutes > ago was/is shown as in state "open"? If you check the bugreport, it's a P3 450 with 256mb ram. It usually takes 24h+ using 20+ processes that write 5kb files (bit larger than the fragment size) to reproduce it on my T42. Like on a powerfailure, it's going to throw away a few recent changes to the filesystem and is fine afterwards. > > > ciao, > > -- > -- "Jonathan Thornburg [remove -animal to reply]" <[EMAIL PROTECTED]> > t <= 31.Aug.2008: School of Mathematics, U of Southampton, England > t > 1.Sep.2008: Dept of Astronomy, Indiana University, Bloomington, USA > "Washing one's hands of the conflict between the powerful and the > powerless means to side with the powerful, not to be neutral." > -- quote by Freire / poster by Oxfam
