[8] in The Cryptographic File System users list
CFS future plans
daemon@ATHENA.MIT.EDU (Matt Blaze)
Wed Dec 17 21:50:19 1997
From owner-cfs-users@research.att.com Wed Dec 17 21:50:15 1997
Received: from rumor.research.att.com (rumor.research.att.com [192.20.225.9]) by bloom-picayune.MIT.EDU (8.7.6/2.3JIK) with SMTP id VAA03216 for <cfs-mtg@bloom-picayune.mit.edu>; Wed, 17 Dec 1997 21:50:13 -0500
Received: from research.att.com ([135.207.30.100]) by rumor; Wed Dec 17 21:47:17 EST 1997
Received: from amontillado.research.att.com ([135.207.24.32]) by research-clone; Wed Dec 17 21:48:15 EST 1997
Received: from nsa.research.att.com (majordomo@nsa.research.att.com [135.207.24.155])
by amontillado.research.att.com (8.8.7/8.8.7) with ESMTP id VAA12577;
Wed, 17 Dec 1997 21:48:07 -0500 (EST)
Received: (from majordomo@localhost) by nsa.research.att.com (8.7.3/8.7.3) id VAA04351 for cfs-users-list; Wed, 17 Dec 1997 21:47:26 -0500 (EST)
X-Authentication-Warning: nsa.research.att.com: majordomo set sender to owner-cfs-users@nsa.research.att.com using -f
Received: from research.att.com (research.research.att.com [135.205.32.20]) by nsa.research.att.com (8.7.3/8.7.3) with SMTP id VAA04346 for <cfs-users@nsa.research.att.com>; Wed, 17 Dec 1997 21:47:23 -0500 (EST)
Received: from amontillado.research.att.com ([135.207.24.32]) by research; Wed Dec 17 21:45:18 EST 1997
Received: from nsa.research.att.com (root@nsa.research.att.com [135.207.24.155])
by amontillado.research.att.com (8.8.7/8.8.7) with ESMTP id VAA12507
for <cfs-users@research.research.att.com>; Wed, 17 Dec 1997 21:45:17 -0500 (EST)
Received: from nsa.research.att.com (mab@localhost.research.att.com [127.0.0.1]) by nsa.research.att.com (8.7.3/8.7.3) with ESMTP id VAA04293 for <cfs-users@research.research.att.com>; Wed, 17 Dec 1997 21:45:39 -0500 (EST)
Message-Id: <199712180245.VAA04293@nsa.research.att.com>
To: cfs-users@research.att.com
Subject: CFS future plans
Date: Wed, 17 Dec 1997 21:45:39 -0500
From: Matt Blaze <mab@research.att.com>
Sender: owner-cfs-users@research.att.com
Precedence: bulk
Just to let you know, here are my plans for future CFS development, roughly
in priority order:
- Faster DES library. Right now CFS uses a very portable, medium-speed
DES implementation written by Don Mitchell and Jack Lacy a while back.
I plan to integrate Eric Young's SSLEAY code in the next release
(probably 1.4.1, but maybe 1.4.0 if I do another Beta first). This
will result in a significant speedup when CFS does a DES operation
(especially for x86 users), although the effects of the NFS cache will
hide quite a bit of this in practice on typical user workloads.
- Include a fakemountd. Because CFS acts like an NFS server, the client
(your kernel) expects to get a root filehandle for /crypt from the
mount service. So you have to add an entry to /etc/exports for the CFS
mount point for mountd to give out. The CFS server just ignores the
handle, and assumes that anything it didn't give out itself is the root,
so it really isn't important that mountd return a "real" file handle.
Beacause mountd is itself a bit of a security risk (there have been
attacks reported against some configurations), many users who do not
run real NFS servers would prefer not to have to run mountd if they don't
have to. I'm going to include a "fake" mountd that just returns a bogus
handle for any request, which is enough to keep CFS happy and avoids
exposure to any new attacks that might be discovered against the "real"
mountd. This will probably appear in 1.4.1, sooner if someone wants to
bang out some code and send it to me. (The RPC file "mount.x" is included
in the distribution).
- New encryption mode. I've decided to eventually scrap the existing hybrid
of pre-computed OFB plus ECB plus unique vector mode in favor of one
that requires less memory at the expense of a little bit of additional
computation. The main practical problem with CFS is that cfsd grows
hugely with each attached encrypted directory. The new mode will address
one cause of this (see the next item, however), although will kill
backward compatibity. The new mode should remain as secure as it is now
(which is basically equivalent to Rivest's DESX mode with a different key
for each ECB block). The version that implements the new mode, which will
use CBC mode on larger (2K) blocks with a per-block IV based on the
block's offset plus some additional keying material, will be called
CFS version 2.0.0 and will probably be released sometime in the middle
of next year. A "transition" version will support the old mode to allow
converting directories.
- Better file handle management. The other reason cfsd grows has to
do with the way it manages file handles by maintaining an in-memory
index. This will eventually change to a fixed-size in-memory cache of
a disk-based index, to allow better support for very large encrypted
directory trees. Not in the next release, though...
Anyway, please keep the bug reports and patcches coming.
-matt
