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@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.."