This is tiring drivel concerning the CryptoStacker project. It just started yesterday, so don't expect it to be too mature, we all have other things we have to do to pay the rent, right? Anyway, I am posting this to the list because it is kind of a plea for ideas, among other things, there are some tidbits that we need some help on. This particular message seemed to address both of the main ones, so I picked it. Don't complain about bandwidth, ok? Alright, to summarize the needs of the project at this point--> we need: 1) some ideas on a good algorithm for a quick and easy encryption to be used in a simple straight software on-the-fly disk encryption. I know that it's ironic, but it seems that that I and the people interested in funnelling me ideas are mainly deficient in the encryption area... 2) does anybody know how the hell Stacker or DoubleStor or whatever executes the actual interception of the read/write routines and stacks them? I don't get it at all. I am more than willing to learn to get this thing working though. To summarize this message in particular: Hugh: "Hey, wouldn't bell/whistle XXXXXX be a good idea?" Ryan: "Yeah, but can we get the thing to work at all first?" There, you have it. You don't even have to read it if you're not interested... _______________ Message follows:
Here is one method of encrypting whats on a disk that I see as usefull for some, but not all of us. There are real problems for folks like me who have Unix systems as their home systems, but we will leave that as a extra credit problem.
Yeah, I am just concentrating on getting something out there for DOS support. I actually loathe DOS and would rather be supporting UNIX (this would be a lot easier under Unix) but DOS is still a defacto standard and the people who need to be protected will be using DOS a lot...
I see a disk drive (or scsi controler or bus interface or even something that sits in the middle of a scsi cable) with a PCMCIA slot in it. Data gets passed about in the clear if no (or a dummy) card is in the slot. If a real card is in the slot then all data goes though the card before being sent the rest of the way though the interface (might also take the data out via the card, but that makes the card more complex, even if the drive is cheaper, and has other problems). The card is a key, if its in you can read the disk and see the data and it all looks fine. If its not in and you read the disk you see whatever is on the disk, mixed plain and/or cypher text.
I like this idea, but I don't know about having ALL data go through the encryption system. What about the idea of setting up a 'secure' partition and a 'fast' partition and having a device controller that would only run stuff sent to the 'secure' partition through the crypto system? I also don't know about the practicality of making the thing easy to download your own crypto into it. I think that if I am using a DES chip that is widely understood and trusted that there would be no need for the further complication of letting people hack at it... It would be a really cool option, and it would be a lot closer to allowing people to seize their own security, but I don't think that I can justify adding such a complicated feature at such an early stage.
You now have a 'key', if you don't want the disk read take the key out, breakit it even (if broken the card needs to erase its self as it might be read even in this state by a electron micro scope or some such).
I really like this PCMIA key idea. I don't think that just having a key would be enough though. Say the Secret Service walks in tomorrow and my system is CryptoStacked, and the PCMIA key is dangling out of the slot because I fell asleep programming last night and forgot to take it out and put it in the safe or whatever. <poof> all of that hard earned security is naught. I am much more in favour of a password system to assist the key, much like PGP uses a password system to assist the secret keyring.
There are sevral types of cards one could use in such a system, the ones I would like to see would have all sorts of crypto support hardware and some sort of processer. I want to be able to download my own crypto system into the card (which should be program ONCE), so as I can feal safe in that I control everything that goes on. This might be slower then doing a dedicated chip, but more usefull. Support chips(well features) might include hardware DES,RSA, etc. to speed things up.
I am thinking mainly of finding this much rumored DES chip and trying it out on a dedicated board. I had another idea for an initial stepping stone: are ISA cards DMA mapped? If so, howabout a card that simply has the key burned into it's virtual value, but only when it is properly activated? You could easily achieve this by burning a simply program into an EEPROM, and the activation could be something like punching in a code on a keypad attached to the board or something. (this comes to mind because I have a friend that just finished burning some simple programs into EEPROMS and building a simple keycode keypad, integrating them should be a weekend project) That way, I could do the encryption in software for the specified 'secure' partition (until I can get my hands on a DES chip) using the value returned by the EEPROMs as the key. Sound feasable?
If one feals like haveing fun you might be able to use the card remotely, by sending the data (see why I don't want the card to be the interface) over the net and decrypting it localy, then useing it localy or re-encrypting it and sending it back to be used at the other end again. This is more work, but usefull!
Hmm, that could work perhaps, but the main idea was to create a transparant file system encoding system for once the data already is local, there are certainly better packages out there for data transmission security than anything that *I* could cook up... Just look at the flack that the Dolphin guys are getting just for even suggesting something like that...
This would mean that the crypto key cards would need to be designed to be usefull in disks, or as keys in CPU's. The more general the better.
I agree, but a file system CryptoStacker will be hard enough to implement in the first place, I think that I will need to worry about that first.
If one want to play around one could try to have passwords to turn the cards on (digital text/voice, or phyical interface on the back of the card).
Ahh, should have read ahead... I like that voice recognition concept though, but that sounds kind of like a bells/whistles kind of thing too...
One problem I see with this is how low a level it works at, for instance blocks of disk are likely to expand/shrink with ecryption, but for this sort of interface we have to pad. Uck.
Right, that is my main nightmare, what size blocks to use? I just don't quite understand how Stacker does it. the way I see it we have a serious problem because there are at least two different ways of getting data onto or off of a disk. If it was one or the other, I would be able to cope with it by intercepting that method and changing it, but there are at least two fundamentally different ways, reading by bytes and reading by variable length blocks. I'm not sure if it is possible to read by bits or not, I've certainly never needed to do so, but a good scan through the PC interrupts might be necessary... The size of a block of data would not change with DES encryption, would it? I might have a serious misunderstanding about how DES works if the size *DOES** change... Here is a though, the apparant ignorance of which is entirely due to the fact that I just don't understand at all how Stacker works on an intercpet level: How about just encoding each byte seperately, that way I could intercept the byte read/write no problem, and I could intercept the variable block read/write in a similar manner, just break it down into a series of single byte read/write cycles? Is it possible to DES encode a single byte and have it remain a single byte? Is it a reasonably secure idea? I would do some DES research, but I am mail only and it takes WEEKS to poke around ftp sites through the mail, dig? Perhaps someone could send me a nice FAQ? Perhaps someone knows of a nice method by which I *COULD* securely encode a byte to a byte and have it remain a byte using keys and such? I suppose you might have noticed by now, I am a very good software engineer, and a pretty good structure programmer, but only a good machine level programmer, and only a mediocre cryptologist, let's get all of that straight right here.
I have in the back of my head an idea for a NFS like data (in the simple case disk) server. How this might be done is murkey to me right now. My first problem is deciding on where I want the decryption to happen. We keep talking about doing it in the disk drive, but as my example above shows there is no reason to do it that way, and it's a lot safer to pump crypted data through a (maybe leeky) SCSI data cable then to have it all ready decrypted. Maybe what this is trying to tell me is that there is a trueism about decrypting data as close as resonable to the use point (and NOT the source) as one can.
This is all well and good, but I think that getting the damned thing to work at all will be a bitch, much less worrying about perfectly optimal security...
Question is: Is there a good algorithm that can be done totaly in software, that gains more speed & security from beside memory general purpose decryption hardware and even more from dedicated cards?
This is my question exactly, what encryption algorithm...
This is really a protocall questoin, as we should be able to change the crypt algorithm weekly if we want (might need to do this!).
Oi, please... I am worried about finding ONE algorithm, you are already thinking about implementing any number on infinities...
I wonder how this can work if I decide that I need not one, two or three crypt keys, but hundreds! I can see that I am going to have just a few keys for the basic disk keys (can do one per disk) in hardware, and likely hundreds of others that can't (afford or effectivly) use dedicated hardware for.
Well I don't see why any relatively unlimited number of keys couldn't exist. As for those people that can't afford to use dedicated hardware, there is still the less secure idea of having the key stored on a floppy that would be inserted at load time and read into memory. This would have the obvious disadvantage of having the key sitting around in memory, a sitting duck (especially for people who leave their systems on all of the time, like me, as soon and the Nazis learned about systems like these then 'Run a key scanning program on the system to be confiscated' would just become step one in their procedure, would be a hole even if the keys were password protected) but it would be better than nothing at all, and the speed problems could be dealt with by using the multiple partition method that I described earlier, having a 'secure' virtual disk where all of your data goes, and a seperate 'fast' virtual disk which is unencrypted where all of your programs and such go.
Have fun, theres work to be done! ||ugh Daniel hugh@toad.com
Yes, but you know, the more I think about it, the easier it looks... my two main problems right now are: 1) What algorithm? How? 2) How the hell to intercept the read/write routines? After that, the rest is just writing code. Code I can do, code is no problem... -Ryan the Bit Wallah
A related topic to encrypted disk drives. Anybody who has a desire to see their data around long term makes backups of their drives. At least one of these backups is usually physically near the drive in question. What good it is to have an encrypted disk if the backups are not also encrypted? Backups occur at the file system level, where an encrypted file system does not appear encrypted, so that work here does not directly leverage to encrypted backups. Eric
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. 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 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. Your model seems to be that of intercepting interrupts to the disk. This could be made to work, but is the wrong way to do it. If you insist on that, though, any good PC reference book will tell you what the disk interrupt vector in the BIOS is. Ralf Brown's interrupt list also contains the relevant data in schematic form. The proper way to do this is as a device driver, however. Grabbing interrupts is messy and prone to interference. Many anti-virus programs monitor the disk interrupt to make sure that nobody uses it unauthorized. A device driver is the intended way to create new devices, like an encrypted disk. There are complete books about writing device drivers; you will need one of these or some other good DOS programming book which explains how to write one. There are lots of subtleties about them. 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. 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. 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. 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. 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. 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. 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? Eric
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?
Why not have the device driver create a file (possibly of varying sizes) on the hard drive which the encryption device driver then makes look like another drive?!? This is how the compression programs work, seems to me a pretty viable way to solve the encrypted drive problem as well. A good place to start on this would be something like DOS's VDISK device driver, it maps a portion of RAM into a RAM-disk... a good way to understand how a DOS device driver should map something that has no disk-like characteristics into disk-like characteristics.
On Thu, 3 Jun 1993, Patrick E. Hykkonen wrote:
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
Why not have the device driver create a file (possibly of varying sizes) on the hard drive which the encryption device driver then makes look like another drive?!? This is how the compression programs work, seems to me a pretty
Hmm, nix on that, I would have to do some sector remapping, which would not only slow it down and make it more vulnerable, it would just be more crap that I would have to deal with which might crash the thing in the long run. Besides, I think that most people using this would actually PREFER to have more that one partition, with one unprotected. This would allow you to use the setup that I have mentioned before, with one 'fast' partition and one 'secure' partition. You would simply have to make sure that the system was booted from a 'fast' partition. Quick, simple, stuff that you don't have to be a genius to make work. (remember we are talking about protecting non-cypherpunks here as well as us computer gurus) I would like to implement a system in the future which would do compression as well as encryption (are there any good algorithms that just happpen to do both at the same time? Maybe somebody should get on that, it would certainly be useful) and that would require a system like you mention, but I will stay with simple for the first version. -Ryan the Bit Wallah
On Thu, 3 Jun 1993, Eric Hughes wrote:
A related topic to encrypted disk drives. Anybody who has a desire to see their data around long term makes backups of their drives. At least one of these backups is usually physically near the drive in question.
What good it is to have an encrypted disk if the backups are not also encrypted?
Backups occur at the file system level, where an encrypted file system does not appear encrypted, so that work here does not directly leverage to encrypted backups.
This is a good point. The only thing that I can think of in response is that there is now a need for a cryptobackup system. I can easily see how this could be accomplished with disk spanning, but I'm not sure that we could create something to work with all of the different tape drive standards. Perhaps just write a freeware system that could handle disk spanning and a few major, common tape systems (Colorado, etc...) I have to admit, that does present a minor problem. There is, of course, another way to do it which would speed things up by not having the date come from the disk, get decrypted by my driver and then get immediately encrypted agian before they get to the backup, and that is to simply operate the backup system as normally from the 'fast' partition with the encryption driver turned OFF. You back up the secure partition that way, and then whatever goes to the tape is pure garbage, and then you just turn the driver back on by rebooting. When you want to restore you simply turn the driver off, restore to the secure partition, and reboot to get your data again. No matter what kind of a system you are using, you are still going to need some unencrypted disk space to boot from, so that is where you stick your backup programs. Hell, the more I think about it, it won't be any problem at all...
Eric
-Ryan the Bit Wallah
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
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
As for those people that can't afford to use dedicated hardware, there is still the less secure idea of having the key stored on a floppy that would be inserted at load time and read into memory. This would have the obvious disadvantage of having the key sitting around in memory, a sitting duck (especially for people who leave their systems on all of the time, like me, as soon and the Nazis learned about systems like these then 'Run a key scanning program on the system to be confiscated' would just become step one in their procedure, would be a hole even if the keys were password protected) but it would be better than nothing at all, and the speed problems could be dealt with by using the multiple partition method that I described earlier, having a 'secure' virtual disk where all of your data goes, and a seperate 'fast' virtual disk which is unencrypted where all of your programs and such go.
Hmmm... I have a suggestion to make keeping the key in memory a little more safe, though I don't think there is way to prevent a properly resourced person/agency/enemy from getting it (or any other data in the RAM of the computer). You first need a machine which has a supervisor state, which *only* the OS can run in. Your cryptostacker will be part of the OS and as such, user processes cannot access its memory. This way, the attacking agency will have difficulty just running any old program to copy all of the CPU's memory to a disk. The only way to add new programs to the supervisor state (OS) would be if the machine is power up in a special way (with a certian boot disk for example) so that once the machine is running there is *no* software method to read any OS data. You would also want to avoid storing the crypto key at a fixed memory location. Allocate some memory at a variable location at each startup and store this location *only* in a register. This should make it even more difficult to get the key, because you would need to be able to check the supervisor stack to find the right register to find the location of the key. This raises the question of just how much work an agency goes through when it is first confiscating a machine to ensure that they can get at all the machines data. If the first thing they do is turn the machine off to be able to pack it up, then you are all set. (Assuming you didn't manage to turn it off before you lost control of the machine.) What kinds of things can you do to your home machine to make more tamper proof? If you have an "easy access" case, how about installing a micro switch that will reset the machine (or power cycle the system) when its opened. --- Nick MacDonald | NMD on IRC i6t4@jupiter.sun.csd.unb.ca | PGP 2.1 Public key available via finger
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.
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.
This probably goes without saying, but just to make sure... Since you are talking about using a partition, and partitions do not often change in size (it implies a lot of backup and restore work to change a partition size normally) then you could generate all the keys for all the (known and fixed number of) tracks in advance. The first thing the user should do after generating all the keys is to make **many** backups, perhaps all with different keys to encrypt the keys. No one wants to lose a whole partition because a floppy wore out and broke down! The other interesting thing about encrypting per track... it exemplifies the trade offs often associated with computing... Usually they preach that all files should be contiguous (all sectors on the same track if possible) but for the most secure encryption of a file in this cryptostacker you would want files to be on as many different tracks as possible. --- Nick MacDonald | NMD on IRC i6t4@jupiter.sun.csd.unb.ca | PGP 2.1 Public key available via finger
participants (4)
-
Eric Hughes -
Nickey MacDonald -
pat＠tstc.edu -
RYAN Alan Porter