[175] in The Cryptographic File System users list
BOUNCE cfs-users@nsa.research.att.com: Non-member submission from [Jonathan Tho (fwd)
daemon@ATHENA.MIT.EDU (Matt Blaze)
Fri Mar 17 04:30:05 2000
From owner-cfs-users@nsa.research.att.com Fri Mar 17 09:30:05 2000
Return-Path: <owner-cfs-users@nsa.research.att.com>
Delivered-To: cfs-mtg@CHARON2.mit.edu
Received: (qmail 12114 invoked from network); 17 Mar 2000 09:30:05 -0000
Received: from h-135-207-30-103.research.att.com (HELO mail-green.research.att.com) (135.207.30.103)
by charon2.mit.edu with SMTP; 17 Mar 2000 09:30:05 -0000
Received: from amontillado.research.att.com (amontillado.research.att.com [135.207.24.32])
by mail-green.research.att.com (Postfix) with ESMTP
id 471F81E05B; Fri, 17 Mar 2000 04:29:50 -0500 (EST)
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 EAA10782;
Fri, 17 Mar 2000 04:30:37 -0500 (EST)
Received: (from majordomo@localhost) by nsa.research.att.com (8.7.3/8.7.3) id EAA02796 for cfs-users-list; Fri, 17 Mar 2000 04:26:15 -0500 (EST)
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by nsa.research.att.com (8.7.3/8.7.3) with ESMTP id EAA02792 for <cfs-users@nsa.research.att.com>; Fri, 17 Mar 2000 04:26:13 -0500 (EST)
Received: by mail-blue.research.att.com (Postfix)
id 148864CE34; Fri, 17 Mar 2000 04:26:59 -0500 (EST)
Delivered-To: cfs-users@research.att.com
Received: from mx.crypto.com (unknown [207.140.168.138])
by mail-blue.research.att.com (Postfix) with ESMTP id F058C4CE2E
for <cfs-users@research.att.com>; Fri, 17 Mar 2000 04:26:58 -0500 (EST)
Received: from fbi.crypto.com (localhost [127.0.0.1])
by mx.crypto.com (8.9.3/8.9.3) with ESMTP id EAA26720
for <cfs-users@research.att.com>; Fri, 17 Mar 2000 04:26:58 -0500 (EST)
Received: from fbi.crypto.com (mab@localhost)
by fbi.crypto.com (8.9.3/8.9.3) with ESMTP id EAA01701
for <cfs-users@research.att.com>; Fri, 17 Mar 2000 04:28:15 -0500
Message-Id: <200003170928.EAA01701@fbi.crypto.com>
X-Authentication-Warning: fbi.crypto.com: mab owned process doing -bs
X-Mailer: exmh version 2.1.1 10/15/1999
To: cfs-users@research.att.com
Subject: BOUNCE cfs-users@nsa.research.att.com: Non-member submission from [Jonathan Tho (fwd)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 17 Mar 2000 04:28:14 -0500
From: Matt Blaze <mab@research.att.com>
Sender: owner-cfs-users@research.att.com
Precedence: bulk
------- Forwarded Message
Date: Fri, 17 Mar 2000 10:19:45 +0100
Message-Id: <200003170919.KAA20142@davinci.thp.univie.ac.at>
To: cfs-users@research.att.com
Subject: CFS support for old/slow machines (was: Re: CFS Status)
From: Jonathan Thornburg <jthorn@galileo.thp.univie.ac.at>
Cc: Jonathan Thornburg <jthorn@galileo.thp.univie.ac.at>
Sender: jthorn@davinci.thp.univie.ac.at
[[I sent an earlier version of this message to cfs-users on Mon 13 Mar 2000,
but it appears to have disappeared -- I think the anti-spam filter may have
eaten it due to my sending from a different machine. At any rate, if anyone
sees this twice, I apologise for the duplication.]]
In a recent message to the mailing list, Matt Blaze wrote
> As you've probably noticed, the last release of CFS was over two years ago.
> I've got a bunch of updates I've been sitting on, with the hope of getting
> out a minor release "any day now", with a major release to follow once
> I can set aside some coding time.
Just to make the context of my comments below clear, I've been a
satisfied cfs user for about 7 years now, and I *very* much appreciate
Matt's making his code available all these years.
> there are a number
> of design decisions I made eight years ago that seem quaint today, and serve
> to make the code a bit unwieldy.
>
> Mainly, computers have gotten fast enough that doing all cryptographic
> operations on file-system-sized blocks (in, e.g., CBC mode over entire
> 8KB blocks) no longer carries a significant latency penalty.
I'm still running cfs on a 1992-vintage computer (Sun ELC, about like
a 486/33 for this sort of stuff), which I can't easily upgrade due to
some expensive commercial software which is only licensed for this
machine (another advantage of Free/Libre software!). On this machine
cfs is slow, but quite usable for my main use, which is keeping E-mail
archives which I'd like to stay confidential even when I scrap a disk.
I've accumulated a lot of such files over the years. So...
* I'd like to see continued "reasonable" performance on slower machines.
(This might be a compile-time option if need be.)
* I'd *very* much like to see continued backward compatability with
existing on-disk cfs directory trees, i.e. new cfsd can still read/write
stuff which was originally encrypted 5 years ago.
* In some discussions on the list 4 or 5 years ago, Matt remarked that
he didn't realise that people actually wanted cname and ccat. There
has been a bit of further discussion of cname/ccat, but not much.
IMHO, these programs are *essential* for any serious use of cfs: they
-- and *only* they -- allow cfs-encrypted files to be recovered from
(encrypted) backups even without admin priviliges on the recovery
machine (and hence without cfsd installed/running).
[In fact, I still use the "old" cfs directory format
(cmkdir -o), because as of the last time I checked,
cname/ccat weren't supported for the "new" format.]
To put it another way, without cname/ccat, I wouldn't dare use cfs to
store my only copies of valuable files. So I'd *very* much like to
see the functionality of cname/ccat preserved in future releases.
- --
- -- Jonathan Thornburg <jthorn@galileo.thp.univie.ac.at>
http://www.thp.univie.ac.at/~jthorn/home.html
Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
"Stocks are now at what looks like a permanent high plateau" -- noted
economist Irving Fisher, 2 weeks before the 1929 stock market crash
------- End of Forwarded Message
