openbsd encrypted fs

[zem]

On 23 Oct 2001, Dr. Evil wrote:

> > vnconfig -ck svnd0 diskimage
[...]
>
> I am aware of that, but it's a hack, and it doesn't work well.  For
> example, it has no way of detecting when you enter an incorrect
> password.

Sure.  Just noting that the capability is there, since it's easy to
overlook.  It works reliably in my experience.

> Anyway, for an OS which prides itself on built-in crypto,
> why do we have to mess around with loopback?  There are many FS
> features, such as being able to change read, write end execute perms
> for owner, group and root, which don't require a loopback FS.  How is
> this any different from that?  If it were really integrated crypto, I
> would be able to do
>
> mount -k /dev/sd0c

This I don't understand.

Can you describe a scenario under which an encrypted fs is valuable enough
to justify typing one command, but not two?  OpenBSD's target audience is
not exactly clueless newbies.

Or is speed so important that you'd sacrifice security?  Any encrypted fs
will take a performance hit; I think you'll find loopback overhead is
insignificant next to the crypto.

> and it would do the right thing.  Even better, I would be prompted for
> a password during boot so it could boot from an encrypted fs.

Is booting from an encrypted fs ever useful?  Use read-only media if
tampering is a concern.  Configure and mount other encrypted filesystems
from /etc/rc.  If you can install and maintain OpenBSD, you can manage
that.

> This is a glaring hole in OpenBSD's crypt-everywhere mantra.

It's worth noting their primary goal is network security, not crypto.
Rubber hoses don't factor significantly in their threat model.


-- 
mailto:zem at zip.com.au F289 2BDB 1DA0 F4C4 DC87 EC36 B2E3 4E75 C853 FD93
http://zem.squidly.org/ "I'm invisible, I'm invisible, I'm invisible.."