On Thu, 3 Jun 1993, Eric Hughes wrote:
This is tiring drivel concerning the CryptoStacker project.
If you want help, it is wise not to recklessly insult those who are offering it. By your own admission, you do not have a lot of experience here; you seem to be saying "I know exactly what I don't know," which, may I add, is a common delusion of the inexperienced.
Oh please, not a flame... I'm trying to create something here, and I need a lot of help, since everyone seems to know exactly how this should be done but none of them want to actually get off of their heinies and write it. The last thing that I need is to start getting flamed, the whole project will rapidly go down the tubes...
You seem to have fixed a model of how the encrypted disk would work and don't want to debate it. The model is exactly that which requires the most scrutiny, because it has the most far reaching effects. If the model is flawed somehow, that's what you want to know before you begin, not six months later.
I am paying very close attention to the suggestions on overall format, you may have noticed that my concept has changed from a hardware PGP encryption of the entire disk with PCMIA keys to a more realistic DES software encryption through device drivers and multiple partitions. I am certainly not closed off to ideas, and the last thing I need, as I said before, is to start getting flamed.
I take it that you want people to use this software after it is written. if so, then pay close attention to user acceptance issues such as performance and key handling. You neglect them at your own risk.
I am certainly not neglecting either issue, performance is one of the main reasons why I am interested in NOT doing sector remapping and compression along with the encryption, and I am trying to find a convinient method for keeping keys that an end user would be happy with. Among the suggestions at hand: An ISA card with the key burned into EEPROMS and a keypad attached for verification of user ID PCMIA cards holding keys and a mandatory PCMIA slot Users typing long keys in manually Keys held on floppy disks Keys held on the HD itself I believe that keys held on floppies with password verification to be the most feasable, the easiest and the most likely to be understood and accepted by end users. Please stop flaming me, I'm doing the best I can here...
I would suggest that you first version just be a device driver that has no encryption, but only the hook for it. The device driver skeleton for a disk will be difficult enough, as you have to support a whole lot of operations just so you can have a place to put the encryption. This is exactly the software infrastructure problem in another context.
Yes, I can see the advantages of using a device driver for this application. I am now doing research on just that. The idea of setting up the initial version to simply pass through data unharmed is also a very useful suggestion. Thank you.
After you have a device driver skeleton working, you can add both hardware and software encryption modules. There is no need to be exclusive about this. It is clear to me from your comments that you haven't timed any DES routines and done a calculation of increased latency times, and although I hate to see code development go to waste, it's your time, not mine.
As far as picking an encryption algorithm, use DES. DES is the fastest symmetric keyed block cipher that is thought to be reasonably secure. DES is not particularly fast in software; it was designed as a hardware standard and does lots of bit manipulations. DES is fast enough for serial communications, but that 1000 times less the bandwidth than a hard disk.
Is it just my impression or did you just tell me that 1) DES is too slow to use, I am stupid for trying. 2) DES is what I should use. What the hell did I do to deserve getting flamed by someone who I so respected about ten minutes ago? Do you instinctively do this because I don't yet understand a few highly technical concepts yet? Would you rather this whole project just get scrapped just because I am not yet as proficient in this area as you? How did you learn, did people flame you when you tried to create something and asked for advice? What the hell, I'm just trying to help. You talk about how I should be careful about inadvertently trampling on the people giving me advice. I am sorry I certainly did not mean to (and I think that you will notice that later in the message I specifically thanked him several times for his input) but what about you specifically and intentionally insulting the guy who is actually trying to WRITE the thing? I have other things to do, I am a professional programmer and I get payed plenty to write code for other people. What I am doing here is trying to write some code for EVERYONE for FREE and I am VOLUNTEERING my time. (lots of it, I might add)
Of course, you don't want to run DES in codebook (aka naive)mode. (Codebook mode is where you just simply map block to block; the problem is that identical blocks map to identical blocks.) You'll want some sort of other mode, like a counter mode, to make sure you don't get identical ciphertexts. It is also a bad idea to encrypt the whole disk with one key; it makes brute force searches much easier.
I see. How do codebook and counter mode relate to the layering that I hear about (ie, single, double, triple DES) are these simply single or multiple layers of these modes, or did I miss something? (I still have a shortage of good cypto books at my command, I have three that I think will be very helpful on order at the local university library)
Your keying material should be long. I earlier suggested one key per track. These keys are going to have to be stored somewhere, and the disk is the wrong place for it, clearly. This implies that the user is going to have to have some key-holding device (likely a diskette) which will be necessary in order to unlock the partition. the keying material should be password protected. This device will be have to used at boot time if anything necessary to boot is stored on the encrypted partition.
I agree about length and multitude. How does the key length affect the speed of the algorithm? I am also concerned about having the keys sitting around in memory once they are read from the disk. This would just open the system up to somebody running a key scanning program on your system and grabbing the keys right out of memory. I'm still not sure what to do about this. It is a really good reason to go to PCMIA cards with the PCMIA DMA mapped in the future, but I can't quite think of a good solution right now...
Keying material will need to be backed up. This should be made as painless as possible, otherwise there will be plenty of people losing whole drives.
Yes, that shouldn't be any problem. I am thinking more an more that the guys who wrote Stacker knew what they were doing... I forsee a seperate utility program which would sit around on the uncompressed partition for dealing with keys and such, this would be where I would handle key backups.
Keys in the driver should time out after some specifiable period. 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.
I thought of this as well as a possible solution to the problem of having the key sitting around in memory, but it really seems to me like a great way to lose data by crashing programs. I just don't see how I could make it timeout gracefully and not crash whatever is running. Something that I did think of though, is 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. This would provide the timer support and still not be horrible likely to wreck the hell out of something and kill some data.
This model of using a device driver means that there is going to have to be at least two partitions on the disk: one to boot from, and one to be encrypted. The device driver itself and the operating system can't be on the encrypted disk, because those components must be loaded before the encrypted disk is accessible. Most people are not going to go out and buy a new disk to be the encrypted partition. Thus, this is going to mean a full backup of the existing disk, an operation with FDISK to do the partitioning, then, assuming the driver works right the first time, restoring everything else on the encrypted partition. What is the effect of _this_ on user acceptance?
This looks awfully flamish to me too, but I'll let it pass... I think that this is likely to be the biggest problem with my system as I am considering it. An obvious way around this would be to use a system which does sector remapping and stores the entire file system in one huge file a la Stacker, so that we don't need to actually physically partition the disk. I can think about how to implement a system like this after I get a non-sector indexing system working. I think that a system like the aforementioned would be possible to painlessly install with an installation program just like the one that Stacker uses to painlessly turn your disk into two virtual disks, one stacked and the other the boot disk, with no backing up and repartitioning involved.
Eric
Much as the flamage has ticked me off, you have provided some of the most helpful information and suggestions to date and I very much appreciate your help. I still truly don't understand what I did to provoke you, other than working on a crypto project, but I do appreciate your help. I can only hope that I caught you late at night or something or perhaps just misunderstood the severity of your insults. -Ryan