CryptoStacker Update

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

This is an update on the CryptoStacker undertaking for those interested. 

I am still at the research/initial_design stage, so any further
suggestions would be welcome.  I am working on several other projects
right now so actual coding will likely not begin in earnest for at least a
week or two, I also do not wish to rush things any more than I need to...

The CryptoStacker engine will probably consist of a block driver style
device driver running under MSDOS which will intercept blocks of data
going to the disk and encrypt them, and intercept blocks of data coming
from the dish and decrypt them.  The system should be completely seamless
and hopefully will remain at one abstraction level.  The intercepted
functions will be the read/write functions of interrupt 13h.

The initial version will be a simple driver with no sector remapping and
will have to be installed on an already existing partition seperate from
the boot partition.  Hopefully in the future it will be possible to create
a false disk by remapping sectors and extracting all drive data from a
single file stored on the physical drive, a la Stacker's one huge file. 
This would allow for installation without the backup and reformatting of
the hard drive.

The keys will initially be stored on floppy disks and password protected. 
For simplicity, I will use one single key for the whole disk during
development, but I hope to be able to provide at least one key per track
in the initial version.  I intend to make the key hooks as modular as
possible and as open as possible in order that the possibility of PCMIA
cards holding keys, barcode keys, datacard keys, etc, will be possible in
the future.

The encryption engine will be completely in software for the widest
possible spread.  This is the single only design consideration that I am
absolutely set upon, and even then I will be glad to implement any advice
on how to make the code as open as possible for future hardware
assistance.  I would like to see it expand into hardware in the future as
encryption hardware hopefully becomes easier to find.

The actual encryption algorithm is a more difficult case to comment on.  I
have done a lot of research on DES, since most of the advice that I have
recieved has pointed in that direction, but I can see that it will be
extremely slow and unwieldy in software.  I would like to use an algorithm
which would be a little more optimized for software but alas, I am more
than a little afraid of the wrath of the cypherexperts who will shun any
non-DES product.  I am looking into the IDEA engine now, and I like the
fact that it also has the capability to take in 8bytes and put out 8bytes,
but that is about all that I know about it.  Things that make DES
attractive to me:

	1) Takes 8 bytes, puts out 8 bytes.

	2) Nonlinear.

	3) It is its own inverse.

	4) I understand it (a factor not to be underestimated)

Things that make it unnattractive:

	1) It is slow as hell, especially with triple iterations.

If anyone knows of some algorithms that have been widely examined which
meet at least a few of the 'pro' arguments and doesn't meet the 'con'
argument, please let me know...

There has been some consideration on the possibility of having the key
time out after a preset interval.  I like the idea as an option to the
user who really wants it, but I have a lot of reservations about how to
make a system time out gracefully when this happens.  I have some ideas
for how to do this with a multitasking OS, but they just seem like hacks
to me, I am looking for elegant solutions.

There has also been some contemplation as to how to shield a key from
being read from a PC's memory.  It has been suggested that I just inform
the user of the security hole and not worry about it.  This seems lazy and
counterproductive to me, and I would like to at least make some effort to
hide the key.  Any good virus writers out there?  Most of my techniques
involve hiding code on mass storage, but I'm sure there are some tricks to
memory someone might suggest.

Well, that seems about it.  I hope that this has been more coherent than
the flurry of replies that marked the beginning of this, and less offensive...


-Ryan
the Bit Wallah