CryptoStacker, long term vision

[Nickey MacDonald]

> 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 at jupiter.sun.csd.unb.ca  | PGP 2.1 Public key available via finger