I am trying to find a convinient method for keeping keys that an end user would be happy with.
There need not be a single method used. This is the whole point of making a system with hooks--hooks for encryption, hooks for key management, hooks for drive control. Not only does this make for more flexible software, but its effect on modularity is striking. One requirement of any keying method, however, is that the keys be physically removable from the locale of the machine. That nixes a couple of the suggestions you mentioned. Any keying material for the volume of data represented by a hard disk will be longer than human memory or tolerance of delay. In an encrypted telecommunications system, the keys should be changed frequently. This is not necessary in the case of encrypted disks. You will know when your drive has been compromised; it won't be there any more. Unlike telecommunications, where one assumes that the eavesdropper has access to all of the data flow at all times, an encrypted hard disk gets looked at once. Of the two remaining solutions on the list, PCMCIA and floppy, there is no reason to chose one over the other. Properly modular software should be able to support both. Floppies will come first because there's no new hardware, but I personally would be much more comfortable using the more robust medium of EEPROM on a removable card.
Yes, I can see the advantages of using a device driver for this application.
The suggestion to use the MSDOS network redirector is also worth heeding. The CD extensions, for example, use it even though that drive is sitting right there in the machine. Using the redirector would allow one to support both separate partitioning and filesystem within a file. Here's another case where modularity wins. Many people may only need a bit of encrypted data, and a one or two Mb file might do it for them. (Sector remapping, BTW, is no big deal.) Again, you don't have to do both at the outset. re: choosing DES for the cipher
Is it just my impression or did you just tell me that 1) DES is too slow to use, I am stupid for trying.
Yes and no.
2) DES is what I should use.
Yes, at first. I remain to be convinced that software encryption of any kind is feasible for efficient bulk hard disk encryption. To be sure, there will always be the need for less efficient but secure storage. As I said in another posting, DES is the fastest trusted symmetric keyed block cipher around. I do not think you are stupid for trying DES. I _will_ think you are stupid, however, if you go ahead and implement it without first doing some estimates on the amount of time it will take and the effect on disk performance and latency. It is planning I am talking about here, not any particular final decision. You should allow hooks in the system for different block ciphers. If you do this, then some sort of algorithm byte should be present in the partition information.
How do codebook and counter mode relate to the layering that I hear about (ie, single, double, triple DES)
Single and multiple DES are still block operations. Codebook and counter modes refer to ways that block ciphers may be used; they are not specific to DES. Re: large amounts of keying material
I agree about length and multitude. How does the key length affect the speed of the algorithm?
There are two lengths here, do not confuse them. The first is the length of the key to the block cipher. The second is the total length of all such keys in aggregate. The first length is not directly relevant; it is the speed of the cipher which it keys that is. For simple iterated DES, however, these coincide. Single DES takes one third as long as triple DES. As far as aggregate length goes, the only time here is for one array indirection, which is miniscule in comparison to the encryption time.
I am also concerned about having the keys sitting around in memory once they are read from the disk.
For a standalone machine, this is not a concern. For a networked machine, one may simply consider that all of memory is available to an intruder. No memory protection is available. There is no way around such a fundamental limitation other than hardware. Therefore, don't worry about it, and inform the user of the issue.
Keys in the driver should time out after some specifiable period.
As I did not mention previously, this is an extremely difficult problem in DOS.
Files that are open when the time-out occurs and the programs that have them open are going to have to be dealt with gracefully.
[...] tying the timer into the int 24 routine which terminates program execution, so that if enough time had passed it would shut down the drive, but only AFTER you have exited your program.
No good. I use Desqview, which multitasks the machine. There's good reason not to require single tasking for this project. Many TSR do effective multitasking already. This is a really sticky problem. The criterion here is that programs with open files whould still be able to access them, and possibly even to write to them. No other access would be permitted. This requires abstraction at the file system level, not the device level, and thus would require mixing abstraction levels. Ick. The logging file systems mentioned in the context of Unix are what is needed here, because the recent activity need not be encrypted. If graceful shutdown cannot be achieved, there will still be times when ungraceful shutdown will be useful. One should not judge in advance another's relative values of information compromise and a slightly corrupted disk. At the very least, there should exist a program to zero out the keying material. Re: conversion from non-encrypted to encrypted
I think that this is likely to be the biggest problem with my system as I am considering it. [...] I think that a system like the aforementioned would be possible to painlessly install with an installation program [...] with no backing up and repartitioning involved.
That's fine, but that program is going to have to get written as well, and it's going to have to be as reliable as a disk optimization program. After each sector write the disk is going to have to be in a stable configuration, so if power fails at that moment, all is not lost. This will not be easy, since you'll be dinking with the partition table all the time. If you can get such a thing working, it would enormously increase the actual usage of the encrypted disk drivers. It is an elegant idea, but a difficult one to implement. Eric