[173] in The Cryptographic File System users list
Re: cfs and list status
daemon@ATHENA.MIT.EDU (Steven M. Bellovin)
Tue Mar 14 18:14:39 2000
From owner-cfs-users@nsa.research.att.com Tue Mar 14 23:14:38 2000
Return-Path: <owner-cfs-users@nsa.research.att.com>
Delivered-To: cfs-mtg@CHARON2.mit.edu
Received: (qmail 15489 invoked from network); 14 Mar 2000 23:14:38 -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; 14 Mar 2000 23:14:38 -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 CD71E1E00E; Tue, 14 Mar 2000 18:14:35 -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 SAA15682;
Tue, 14 Mar 2000 18:15:26 -0500 (EST)
Received: (from majordomo@localhost) by nsa.research.att.com (8.7.3/8.7.3) id SAA02001 for cfs-users-list; Tue, 14 Mar 2000 18:12:19 -0500 (EST)
Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by nsa.research.att.com (8.7.3/8.7.3) with ESMTP id SAA01997 for <cfs-users@nsa.research.att.com>; Tue, 14 Mar 2000 18:12:17 -0500 (EST)
Received: from mx.crypto.com (unknown [207.140.168.138])
by mail-green.research.att.com (Postfix) with ESMTP id 6A52B1E003
for <cfs-users@nsa.research.att.com>; Tue, 14 Mar 2000 18:12:59 -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 SAA26863
for <cfs-users@crypto.com>; Tue, 14 Mar 2000 18:12:59 -0500 (EST)
Received: from fbi.crypto.com (mab@localhost)
by fbi.crypto.com (8.9.3/8.9.3) with ESMTP id SAA27157
for <cfs-users@crypto.com>; Tue, 14 Mar 2000 18:14:15 -0500
X-Authentication-Warning: fbi.crypto.com: mab owned process doing -bs
Delivery-Date: Tue Mar 14 18:06:46 2000
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102])
by mx.crypto.com (8.9.3/8.9.3) with ESMTP id SAA20657
for <mab-cfs@crypto.com>; Tue, 14 Mar 2000 18:06:46 -0500 (EST)
Received: from amontillado.research.att.com (amontillado.research.att.com [135.207.24.32])
by mail-blue.research.att.com (Postfix) with ESMTP id B4EE54CE01
for <mab-cfs@crypto.com>; Tue, 14 Mar 2000 18:06:45 -0500 (EST)
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 SAA15473
for <mab-cfs@crypto.com>; Tue, 14 Mar 2000 18:07:32 -0500 (EST)
Received: from amontillado.research.att.com (amontillado.research.att.com [135.207.24.32]) by nsa.research.att.com (8.7.3/8.7.3) with ESMTP id SAA01993 for <cfs@nsa.research.att.com>; Tue, 14 Mar 2000 18:05:55 -0500 (EST)
Received: from SIGABA.research.att.com (sigaba.research.att.com [135.207.23.169])
by amontillado.research.att.com (8.8.7/8.8.7) with ESMTP id SAA15468
for <cfs@research.att.com>; Tue, 14 Mar 2000 18:07:25 -0500 (EST)
Received: by SIGABA.research.att.com (Postfix, from userid 54047)
id B745041F16; Tue, 14 Mar 2000 18:06:32 -0500 (EST)
X-Mailer: exmh version 2.1.1 10/15/1999
From: "Steven M. Bellovin" <smb@research.att.com>
To: "Bill Dorsey" <dorsey@lila.com>
Cc: cfs-users@research.att.com
Subject: Re: cfs and list status
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 14 Mar 2000 17:48:34 -0500
Message-Id: <20000314230632.B745041F16@SIGABA.research.att.com>
Sender: owner-cfs-users@research.att.com
Precedence: bulk
In message <042a01bf8df9$757c3270$8000000a@Matador>, "Bill Dorsey" writes:
> Steven,
>
> You wrote:
> > And according to
> http://www.microsoft.com/TechNet/win2000/win2ksrv/technote/nt5efs.asp,
> > it also uses single-DES... I'd really like more details on *how* they're
> > using DES, and in particular if they're using OFB mode -- for it, key
> > management is utterly critical.
> >
> I share your concerns about the nature of their implementation. However,
> according to the white paper on EFS by Microsoft (available at their
> web site), they are using DESX, not DES as their cipher. If memory
> serves, DESX is a version of DES extended to use 128-bits of key
> instead of 56. I have not stayed abreast of current thinking of the
> subject, but I have not heard of any significant weaknesses to DESX,
> other that that it would be subject to linear and differential cryptanalysis
> in the same manner that DES was. However, give the key size and the
> difficulty of such attacks, this does not seem like a big deal.
>
Really? Do you have a citation for that? The Web page I cited explicitly
speaks of 56-bit keys.
>
> Note the presence of a "data recovery agent." Ostensibly, this is to
> prevent employees who leave their jobs without transmitting their
> encryption keys to the appropriate personnel from preventing legitimate
> access to company data encrypted on EFS filesystems. It does mean,
> however, that there will always be a minimum of two keypairs which
> may decrypt the contents of any encrypted file on EFS. If EFS users
> were to be ignorant of this fact and don't control both keypairs, their
> data may not be nearly as secure as they think.
Apart from the fact that you generally *want* backup keys for encrypted
storage (my arguments with the U.S. government concern who should hold the
keys, and whether or not there's a need for escrow of communications keys),
the same Microsoft page I cited says that file encryption keys are encrypted
"using one or more key encryption public keys". I haven't played with this
yet, but there is the clear implication that one need not have an
recovery key.
--Steve Bellovin
