Opiated file systems

["Deranged Mutant" <WlkngOwl@unix.asb.com>]

On 14 Jul 96 at 12:48, Adam Back wrote while high on Ritalin:

> Some more thoughts on encrypted file system design criteria.
> A wish list:
> 
> - Choice of secret key encryption algorithms (IDEA, 3DES, MDC, Blowfish)

Nice in theory. Awful in practice.  Requires code for managing keys, 
encrypting and decrypting for ea. algorithm be resident in memory.  
For some systems (MSDOS), free memory is at a premium... (one of the 
reasons SecureDrive is popular is because it takes only 2.5k).  It's 
not worth wasting memory for handling several algorithms when only 
one is going to be used in most cases.
 
> - Multiple architectures (MSDOS, Win31, Win95, WinNT, Unix, Mac)

Ok...
 
> - High performance (hand optimised assembler for each architecture)

So much for maintaining code across platforms.
 
> - Compression

Not worthwhile.  Use a Stacker or JAM driver over the encrypted 
partition on a PC, for instance.  Keep compression and crypto 
separate utilities... keeps bugs from one interfering with another 
and reduces complexity of both drivers; also, if one wants crypto 
w/out compression or compression w/out crypto, no wasted memory (see 
above about RAM being at a premium).

> - Ability to chain algorithms (IDEA and then 3DES for example)

Why?  Doesn't necessarily increase security, esp. considering the 
performance hit (memory... see above, time, key management).

> - Possible to have encrypted file systems on separate partitions, or
> 
> - Encrypted file system located in a file in another file system 
>   (much like DOS stacker drives) this is an ease of use criteria -- I
>   suspect re-partitioning drives would put off many potential users.

Nothing new there.

> - Ease of use.  Graphical user interface for setup and administration
>   functions, with a very simple set of configurations options
>   displayed by default, with more advanced configuration options
>   available in "expert" mode.

A common problem with much crypto these days.

> - All directory and FAT information should be encrypted, so that
>   it is not possible to discover even number of files, or percentage
>   of disk used without the key

Do you understand how such systems work?!?  Every sector is 
encrypted in such systems.  That's not even an issue for most 
encrypted file systems (at least on the PC).

> - Facility for duress key, with the real data hidden in the unused
>   space of the first encrypted drive.  To increase the plausible

Huh?!?

>   deniability all unused blocks within a file system should be filled
>   with garbage, so that it is not possible to tell if there is more
>   data there.

If the algorithm is good, this shouldn't matter.  The only way a 
person could tell if a sector is unused is if that person was able to 
mount the partition already.

> - File system steganographically hidden in files on another file
>   system (encrypted or not).  Support for a wide selection of file
>   formats (Aiff, Wave, Midi, JPEG, GIF, RGB, MPEG).

Now this is getting nutty!!!  Never mind the size, compleixty and 
amazing slowness of such a driver...  you'd have to have audio or video
files of gigabytes in size to be able to store anything of use.

> - Ability to use stegoed file system in files on an unencrypted
>   file system, and boot from a floppy to access stegoed file system,
>   with no other traces left on hard disk.

Why?  The authorities would wonder why you have an 8 Gig JPG on your 
disk and figure you're using it for stego, or you're crazy, or both, 
and have you committed.

Rob.