...

...

...

vnconfig -ck svnd0 diskimage

I don't have a BSD system around to check - what does this approach do?

It creates an loop encrypted loopback FS.

...

...

Anyway, for an OS which prides itself on built-in crypto, why do we have to mess around with loopback? ... 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.

I tested it out and it was about 200% slower than normal, which is not a problem, in my opinion. It's hard to believe that the latency came from the encryption, because the encryption operation is probably not much more computational than the checksum operation, whereas having to write to two FSes at the same time involves all kinds of OS layers and lots of latency.

Is Dr. Evil's concern with loopback just the speed? (Plus the ugly minimal user interface, which is a job for a script.) Machines are enough faster these days that I'd think the only places that's a big hit, other than database apps, are swap space, and you can mostly fix that by buying enough RAM.

No, it has nothing to do with speed. Machines are plenty fast. This is just a kludgy way to do this, and the last time I tried it, I got kernel panics within a day or so of uptime. Not acceptable, obviously. Anyway, the problem is that vnconfig creates a raw disk partition, and then you have to put an FS on top of that, so vnconfig has no way of knowing if you entered the password correctly or not, and basically this method just sucks. My file system already has features such as file ownership, directories, file names, and checksums. I don't need to use some hacked feature to get those features to work. How is encryption any different from those other features? Answer: it isn't. It should just be there.

...

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

Look, how can you not understand this? Isn't this the cypherpunks list we're on here? You might as well ask, "is encrypting my phonecall to grannie ever useful?" If I have a choice between encrypting and not encrypting, why would I not choose encrypting? Surely you can appreciate that a software-only solution to tamper-resistance might have some usefulness? Surely you can understand that, given a choice between booting from a CD and booting from hard disk, it might be an enormous pain to boot from CD all the time, and CDs are far less tamper-resistant than encrypted disk? Surely you can understand that there might be some config files in /etc that contain valuable information in some circumstances? Or perhaps a user wants to make sure that it cannot be proved that a certain application or kernel mod is installed? With the right kind of boot loader and encrypted FS, you could conceal which OS is even being run. Here's one of the biggest security tool design falacies of all time, which you have fallen into: "Off the top of my head, I can't think of a threat model for this configuration option, so no one needs it, so I'll hard-code this limitation into my tool. Why would anyone want to conceal which OS he is running?" There are more threat models than you or I can possibly imagine, so it is horrificly bad to design use contstraints into your security tools architecture. But very few people understand this.

If you've got applications that insist on putting data in /etc or /var, or for log files in general, you have to be careful about the order the system starts in. And if you're worried about people seeing your config files that might show who you communicate with, you could go paranoid about this. IPSEC secrets may be a concern, if stealing/cloning the disk lets someone forge your identity.

Right, thank you, someone understands this. Imagine a laptop with VPN software and config on it, for instance.

...

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

Network security is problem #1 for most servers, but there are a hundred other problems behind it, and physical security is somewhere high up there. Let's put it this way: Let's say you have a DB which stores 100k credit card numbers. This is not uncommon in e-commerce. Stolen credit card numbers have a value of about $5 each on the black market I am told. Suddenly you have data on the machine which are worth $500k. Hmm, do you have armed guards on duty 24 hours a day to protect this $500k asset? Where does one find armed guards who can be trusted? Do you want to spend the $200k/year to hire enough armed guards for 24hour coverage? Where does one find armed guards in countries which don't allow arms? In Singapore do you hire kung fu masters to protect your $500k machine? The answer to all of this is basically "duh, why don't we encrypt the disk?"

Laptop theft belongs in *most* security models.

Yeah, tell that to the MI5 or whichever British branch it is that has lost hundreds of laptops. I used to work at a corporation, and one night, all the laptops in the executive offices were stolen, and people still say, "you don't need FS encryption." I don't understand it. It's an easy feature, and there's basically no performance penalty, so why not have it? "Encryption everywhere" is a good idea, and OpenBSD should adopt it. I can't believe that some people on this list think that storing data in an encrypted format is pointless.

On Tue, 23 Oct 2001, Bill Stewart wrote:

At 01:38 PM 10/23/2001 +1000, zem wrote:

...

On 23 Oct 2001, Dr. Evil wrote:

...

...

vnconfig -ck svnd0 diskimage

I don't have a BSD system around to check - what does this approach do?

Create a loopback device. "-k" means encrypt - cipher is blowfish, there's no way to change it. After vnconfig, /dev/svnd0 becomes a block device; use newfs and mount as with any partition. Here's the man page: http://www.openbsd.org/cgi-bin/man.cgi?query=vnconfig

Is Dr. Evil's concern with loopback just the speed? (Plus the ugly minimal user interface, which is a job for a script.) Machines are enough faster these days that I'd think the only places that's a big hit, other than database apps, are swap space, and you can mostly fix that by buying enough RAM.

The performance hit is acceptable, it's much faster than CFS. OpenBSD's encrypted swap uses the same mechanism.

...

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

Laptop theft belongs in *most* security models.

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