[open-source] File encryption

Jei jei at cc.hut.fi
Tue Jan 29 21:50:28 EST 2002


---------- Forwarded message ----------
Date: Mon, 28 Jan 2002 10:29:43 -0500
From: Matt Blaze <mab at research.att.com>
To: open-source at csl.sri.com
Subject: Re: [open-source] File encryption 

Just to echo Whit's two file encryption virtues (the laptop and
and media over which one has inadequate control): I originally wrote
CFS (a Unix encrypting file system) back in 1991 primarily for my own use,
motivated by the realization that I have two conflicting requirements for
file storage.  I need to be sure that my files will be available, but at the
same time, for at least some of the files, it is also important that they be
kept confidential.

File availability is commonly addressed through replication and frequent,
regular backups.  Backups are hard to do right, but there are network
effects that make it beneficial for many users to share backup
infrastructure - this is the main reason I tolerate having my computers
managed by a staff rather than doing it myself.  Unfortunately, the better
and more useful the backups are at ensuring availability, the less control
over them I have, the less able I am to reliably destroy some piece of
information once it has been backed up, and the more likely it is that a
malicious or careless staff member (or employer) might compromise
confidentiality.

Encryption fits the bill here because it allows me to separate the system
components that I trust for availability from those that I trust for
confidentiality.  In particular, I can manage the confidentiality
component myself - I select and manage the keys, and the encryption runs
on hardware that's under my direct control (my workstation, my laptop, etc)
and whose use is not ordinarily shared with other people.  Of course,
there's also an availability problem here - loss of the key means loss of
all the data encrypted with it - but key backup of individual files
is a much simpler problem than the general file backup problem, not least
of which because file encryption keys are created and changed only
infrequently and are small enough to write down and put in a safe place.

The most critical aspect of CFS's design was to make sure it didn't break
any of the underlying backup mechanisms.   This led naturally to a design
at the file system layer and interfaces - encrypted files were stored as
ordinary, named files, and when the plaintext of a file changed, only the
corresponding encrypted file would change.  This also led to a simple
userland loopback (via NFS) implementation, for which, I decided, any
inefficiency (particularly with respect to cache memory management) was
outweighed by portability.  In retrospect, I would do it the same again today
- if anything the efficiency issues are less important now than they were 11
years ago.

I managed to release the CFS code from AT&T as open source (under a BSD
style license), which is another story by itself.  Unfortunately, the
code is still in use by a lot of people today, despite showing obvious
signs of age (it was originally written on and for an early *86 laptop
running a version of Mach).  It will no longer compile and install on many
modern Unix variants, including Linux, without serious coaxing.  I don't
have the time or resources to maintain it, especially with all the
current platforms which seem to have gratuitous differences in so many
of the interfaces that this code uses.  I also made a number of embarassing
architectural decisions that make it difficult to integrate AES. and to
be brought up to modern standards the whole codebase really should have
been re-written from scratch years ago.   Sadly, CFS, with all its warts,
remains the most portable encrypting file system for Unix today.  I
wish someone would re-write it.

I think the most valuable contribution of CFS at this point is to the
extent it influences other designs, for which I'd encourage people to
look at my 1993 ACM Security conference paper, "A cryptographic file system
for Unix":
	http://www.crypto.com/papers/cfs.ps
	http://www.crypto.com/papers/cfs.pdf

There's also a less interesting paper on a smartcard-based key management
scheme for CFS from the following year's USENIX conference:
	http://www.crypto.com/papers/cfskey.ps

CFS was also the motivation behind remotely-keyed encryption, for which,
sadly, Lucent holds a rather broad patent:
	http://www.crypto.com/papers/card_cipher.ps

(Fortunately, we never patented any of the basic architecture of CFS itself).

-matt








---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com




More information about the cryptography mailing list