[172] in The Cryptographic File System users list
BOUNCE cfs-users@nsa.research.att.com: Non-member submission from ["Steven M. B (fwd)
daemon@ATHENA.MIT.EDU (Matt Blaze)
Tue Mar 14 17:55:19 2000
From owner-cfs-users@nsa.research.att.com Tue Mar 14 22:55:19 2000
Return-Path: <owner-cfs-users@nsa.research.att.com>
Delivered-To: cfs-mtg@CHARON2.mit.edu
Received: (qmail 15318 invoked from network); 14 Mar 2000 22:55:19 -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 22:55:19 -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 837BC1E005; Tue, 14 Mar 2000 17:55:16 -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 RAA15115;
Tue, 14 Mar 2000 17:56:01 -0500 (EST)
Received: (from majordomo@localhost) by nsa.research.att.com (8.7.3/8.7.3) id RAA01894 for cfs-users-list; Tue, 14 Mar 2000 17:52:59 -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 RAA01890 for <cfs-users@nsa.research.att.com>; Tue, 14 Mar 2000 17:52:58 -0500 (EST)
Received: from mx.crypto.com (unknown [207.140.168.138])
by mail-green.research.att.com (Postfix) with ESMTP id 0FFA11E003
for <cfs-users@nsa.research.att.com>; Tue, 14 Mar 2000 17:53:40 -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 RAA00685
for <cfs-users@crypto.com>; Tue, 14 Mar 2000 17:53:39 -0500 (EST)
Received: from fbi.crypto.com (mab@localhost)
by fbi.crypto.com (8.9.3/8.9.3) with ESMTP id RAA26910
for <cfs-users@crypto.com>; Tue, 14 Mar 2000 17:54:56 -0500
Message-Id: <200003142254.RAA26910@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@crypto.com
Subject: BOUNCE cfs-users@nsa.research.att.com: Non-member submission from ["Steven M. B (fwd)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 14 Mar 2000 17:54:56 -0500
From: Matt Blaze <mab@research.att.com>
Sender: owner-cfs-users@research.att.com
Precedence: bulk
------- Forwarded Message
Resent: Tue, 14 Mar 2000 17:54:33 -0500
Resent: cfs-users@crypto.com
Return-Path: owner-cfs-users@nsa.research.att.com
Delivery-Date: Tue Mar 14 17:48:56 2000
Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103])
by mx.crypto.com (8.9.3/8.9.3) with ESMTP id RAA11637
for <mab-cfs@crypto.com>; Tue, 14 Mar 2000 17:48:55 -0500 (EST)
Received: from amontillado.research.att.com (amontillado.research.att.com [135.207.24.32])
by mail-green.research.att.com (Postfix) with ESMTP id 5E1421E003
for <mab-cfs@crypto.com>; Tue, 14 Mar 2000 17:48:55 -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 RAA14902
for <mab-cfs@crypto.com>; Tue, 14 Mar 2000 17:49:44 -0500 (EST)
Received: (from majordomo@localhost) by nsa.research.att.com (8.7.3/8.7.3) id RAA01863; Tue, 14 Mar 2000 17:48:08 -0500 (EST)
Date: Tue, 14 Mar 2000 17:48:08 -0500 (EST)
From: owner-cfs-users@research.att.com
Message-Id: <200003142248.RAA01863@nsa.research.att.com>
X-Authentication-Warning: nsa.research.att.com: majordomo set sender to owner-cfs-users@nsa.research.att.com using -f
To: owner-cfs-users@nsa.research.att.com
Subject: BOUNCE cfs-users@nsa.research.att.com: Non-member submission from ["Steven M. Bellovin" <smb@research.att.com>]
Sender: owner-cfs-users@nsa.research.att.com
>From cfs Tue Mar 14 17:48:06 2000
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 RAA01859 for <cfs-users@nsa.research.att.com>; Tue, 14 Mar 2000 17:48:06 -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 RAA14895;
Tue, 14 Mar 2000 17:49:33 -0500 (EST)
Received: by SIGABA.research.att.com (Postfix, from userid 54047)
id 3AB5641F16; Tue, 14 Mar 2000 17:48:39 -0500 (EST)
Received: from roc (localhost [127.0.0.1])
by SIGABA.research.att.com (Postfix) with ESMTP
id 2BA04400B5; Tue, 14 Mar 2000 17:48:34 -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
Sender: smb@research.att.com
Message-Id: <20000314224839.3AB5641F16@SIGABA.research.att.com>
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
------- End of Forwarded Message
