Re: CryptoStacker, long term vision

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

> 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

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

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

>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

> 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

> 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:

> >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