Re: CryptoStacker, long term vision

[RYAN Alan Porter <ryan@rtfm.mlb.fl.us>]

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