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
[4] # mount -o softdep /dev/sd0a /mnt
[5] # dd if=/dev/arandom bs=1m of=/mnt/imagefile count=...
[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?
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 ...
[ message continues ]

This might be a good time to try my giant softraid diff that makes
crypto useful.


[ message continues ]

Hello Marco,

Greatly appreciate your work on softraid(4). I've decided to play around
with Crypto discipline w/ softraid, created 60GB partition in the
disklabel, marked it as RAID:

  n:        117194175        195382530    RAID                   

then created the softraid0 device, backup by sd0n:

scsibus2 at softraid0: 1 targets, initiator 1
sd1 at scsibus2 targ 0 lun 0: <OPENBSD, SR CRYPTO, 002> SCSI2 0/direct
fixed
sd1: 57223MB, 7294 cyl, 255 head, 63 sec, 512 bytes/sec, 117194096 sec
total

Everything seems fine, performance is not bad at all, ~4% higher than
svnd0 on the same box. (could be the difference of Blowfish_CBC vs
AES_XTS). However, when playing with tools like bonnie++, my T61 w/
2.4GHZ duo becomes barely responsive. But, it's perfectly understandable,
writing massive amounts of data to crypto backed device with putc() is 
insane.

Now, on boot, the softraid0 doesn't attach itself to sd0n, perhaps not
implemented yet? I was wondering if there were any plans to create
support for crypto devices so that they could be mounted on boot as
specified in fstab(5).

Also, is there any plans to be able  to specify which key size you'd 
want to use with AES_XTS?

Thank you.

[ message continues ]

Yes it is.  It really is meant as an actual disk device that moves
normal amounts of data.  The putc/getc stuff doesn't prove or disprove

Currently this is deliberate because we haven't implemented boot support
yet.  This in time will be implemented but not until we can get it
right.  For now look at the benefit that the disk is there without

Maybe, it is easy enough to implement and if someone can convince me of

[ message continues ]

Yes, but someone needs to wrtie the bits for /etc/rc to implement this. 
We also plan to add bootloader support for root on softraid, but that

The kernel code already mostly support AES-XTS-128, but it can only create
the volume with AES-XTS-256 at present. Supporting this will require
extending the BIOCCREATERAID ioctl to allow it to specify which algorithm
to use.

-d

[ message continues ]

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

i'm not super keen on cfs - managed to crash it horribly under load a

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


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



i'd go with "try it and see". i never bothered messing about with

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?

[ message continues ]

I know some people have done this, but the code doesn't like it.  I'd
stick with normal files.

[ message continues ]

I have done file, partition, and whole disk; each one gets progressively 
slower.

[ message continues ]

prepare to wait a few days... there is known plaintext at specific
locations anyway, disklabel, filesystem metadata,...


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

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.


No problem, for the paranoid however you might want to read up on the


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

[ message continues ]

very little really.  especially if you create the inner
filesystem/disklabel with anything other than the default of all space
in one partition.  it's easy to verify a correctly guessed key, but

CBC only for disk blocks.  Each disk block is independent, otherwise

Not sure what you mean here.  There's only 23 hard drives? :)

[ message continues ]

Afaik there are (can be?) collisions in images bigger than ~40GB because
of blowfishs block size.

[ message continues ]

Right.  Unfortunately, the only online reference I could find
indicating the significance of this is wikipedia's talk (!) page for
birthday attack.  Neither the actual birthday attack page nor the disk
encryption theory page mention it at all, and just about every other
search hit is a cheap wikipedia knockoff.  So sad.

[ message continues ]

I'd like to publicly thank all those who are contributing to this
thread -- the discussion is very informative.

I suggested initially creating the imagefile with
[5] # dd if=/dev/arandom bs=1m of=/mnt/imagefile count=...

Several people have commented on this from the perspective of
cryptographic security (not leaking where data has & hasn't been
written).  However, I actually had a rather different goal in mind:
I'm thinking of squeezing 5-10% more space out of a given-size disk
by tuning the underlying filesystem parameters to 'newfs':

(a) Since the underlying filesystem will ony hold a single huge
    'imagefile', it only needs one inode (or maybe a handful to allow
    for directories), so I can specify something like 'newfs -i 1048576'
    or even 'newfs -i 1073741824'.

(b) If I pre-allocate the imagefile with dd from /dev/arandom, all its
    blocks will actually be allocated, so it won't grow thereafter, and
    hence no more block allocations will be needed, so I (I think) can
    save the default 5% freespace via 'newfs -m 0'.  In contrast, an
    initially-zeroed imagefile would be sparse, with most blocks not
    actually allocated, so I'd need the freespace reserve to make
    imagefile block allocation reasonably fast & vaguely-contiguous-on-disk
    as the encrypted filesystem is used.

Browsing newfs(8), '-g very_big_number -h small_number' also look useful.

Perhaps I'm being overly agressive in my disk-space optimization...
but I've been using computers for 30+ years, and every disk I've ever
used has reached an equilibrium of "over-full", so an easy 5-10% is
tempting...

-- 
-- "Jonathan Thornburg [remove -animal to reply]" <J.Thornburg@soton.ac-zebra.uk>
   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."
                  ...
[ message continues ]

On Sun, Jul 20, 2008 at 3:00 AM, Jonathan Thornburg

wrong. if you write just one sector at the end, yes, you'll create a
sparse file. "dd if=/dev/zero of=image.bin bs=64k" will actually write
to each and every one of those sectors.

CK

-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?

[ message continues ]

until you cp or tar it. :)

[ message continues ]