If you have some time and a spare disk, why not experiment with the 3
or 4 options available to you before settling on one.
- cfs
- svnd backed by a file in a filesystem
- svnd backed by a whole slice on disk
- softraid w/ crypto
softraid w/ crypto is still kind of a work in progress, but it's very
functional already. i'm running it on my laptop for all of /home. just
make sure you use the latest diff (posted to tech@)
On Sat, Jul 19, 2008 at 9:04 AM, Jonathan Thornburg
<[EMAIL PROTECTED]> 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 not super keen on cfs - managed to crash it horribly under load a
while back and wasn't terribly impressed with it.
> 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
> [4] # mount -o softdep /dev/sd0a /mnt
> [5] # dd if=/dev/arandom bs=1m of=/mnt/imagefile count=...
i guess i can understand use of arandom so as not to leak where data
has and hasn't been written... if you're just evaluating crypto
solutions for performance and ease of use, you could create a sparse
file by DD'ing a block way out at the end... "bs=1k count=1
skip=1024000" would give you a 1G file that uses 1-8K on disk
(initially) depending on how you set up the filesystem.
> [6] # vnconfig -vck -K 100000 -S /var/saltfile svnd0 /mnt/imagefile
> [7] # disklabel svnd0 ... create encrypted openbsd-partition "a"
> [8] # newfs /dev/svnd0a
> [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?
those are them. you might want to read up on bioctl, though.
> 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?
man vnconfig says the cipher is blowfish. the source says:
blf_ecb_encrypt(vnd->sc_keyctx, iv, sizeof(iv));
if (encrypt)
blf_cbc_encrypt(vnd->sc_keyctx, iv, addr, bsize);
else
blf_cbc_decrypt(vnd->sc_keyctx, iv, addr, bsize);
> 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?
largest crypto disk i've built is 500G. takes a while to fsck but it works.
> 5. Is there any problem with using softdep in steps [4] and [9]?
not that i've noticed
> 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?
i'd go with "try it and see". i never bothered messing about with
those settings... the defaults were good enough.
> 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"?
again, try it and see. i never hit this untarring ports or src...
maybe i was lucky.
--
GDB has a 'break' feature; why doesn't it have 'fix' too?
