On Saturday, February 2, 2002, at 10:58 PM, Dr. Evil wrote:
>>> Encrypted disks are still rare, but that is because raids
>>> that seize people's computers are rare. Of course it is
>>> regrettable that disk encryption is not part of the operating
>>> system -- but if Microsoft put it in before we had a strong,
>>> widely adopted system, they would doubtless muck it up.
>>
>> Even if they do it after they will still muck it up.
>
> Microsoft does support encrypted disks. They do in Windows XP and I
> think they may have had it earlier too. Who doesn't support encrypted
> disk? The open source guys. There is only _one_ open source OS that
Encrypting disks on server type systems is of really marginal utility.
You have 2 choices of when to "mount" a volume, on boot, or on demand.
For a system that runs for long periods of time:
example01: uptime
9:51AM up 292 days, 23:46, 22 users, load averages: 0.09, 0.09, 0.08
[iso:~] petro% uptime
10:41AM up 12 days, 9:12, 7 users, load averages: 0.81, 0.58, 0.44
[petro@lists petro]$ uptime
10:29am up 45 days, 18:37, 5 users, load average: 0.00, 0.00, 0.00
Mounting a file system, especially the OS/Application parts (as opposed to
user or "home" directories) is, quite frankly silly. Once the disk is
mounted an attacker has plenty of access to the volume, and the disk is
likely to stay mounted for weeks at a time. To have to enter a password to
boot the machine can really be a pain in the ass, especially if the one or
two people who know the password aren't around when you need the machine
restarted.
Mounting home directories makes more sense, and the proper way to do that
is when the user logs in, but you still have the issue of the contents
being exposed while they are logged in.
Allowing the user--any user--to mount and unmount encrypted filesystems at
will *is* the proper way to do this, and that is, on Unix, best done via
some sort of loopback filesystem It allows for all of the things that
Admins want to be able to do with their systems, back them up, move files
from one disk to another, volume management (like LVM) etc. *and* allows
the end user to *control their own level of privacy*.
> currently supports encrypted disk in a non-kludge way (loopback FS
> counts as a kludge). That is Mandrake Linux in their 8.2 beta
No, Blazes local NFS is a kludge. Some sort of Loopback is the *right*
way to go about this for most needs.
> version. That's it. OpenBSD with its "crypto everywhere"? No, it
> should be "crypto everywhere except on the disk." The upcoming
Funny, aren't they the ones that allow the use of an encrypted swap
partition? Now *that* is the right way to do it.
> versions of ResierFS for Linux will support plugable modules which
> will allow easier encryption, so eventually it will be availbe for
> Linux. I just wish OpenBSD would get this in there so they could
> actually live up to their reputation.
I'd prefer they get dual processor support working first. For that
much encryption, they're going to need it.
--
Crypto is about a helluva lot more than just PGP and RSA...it's about
building the I-beams and sheetrock that will allow robust structures to be
built, it's about the railroad lines and power lines that will connect the
structures, and it's about creating Galt's Gulch in cyberspace, where it
belongs.--Tim May
