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