[171] in The Cryptographic File System users list
Re: cfs and list status
daemon@ATHENA.MIT.EDU (Bill Dorsey)
Tue Mar 14 16:09:24 2000
From owner-cfs-users@nsa.research.att.com Tue Mar 14 21:09:24 2000
Return-Path: <owner-cfs-users@nsa.research.att.com>
Delivered-To: cfs-mtg@CHARON2.mit.edu
Received: (qmail 14418 invoked from network); 14 Mar 2000 21:09:23 -0000
Received: from mail-blue.research.att.com (135.207.30.102)
by charon2.mit.edu with SMTP; 14 Mar 2000 21:09:23 -0000
Received: from amontillado.research.att.com (amontillado.research.att.com [135.207.24.32])
by mail-blue.research.att.com (Postfix) with ESMTP
id 6C2714CE05; Tue, 14 Mar 2000 16:09:21 -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 QAA11305;
Tue, 14 Mar 2000 16:10:08 -0500 (EST)
Received: (from majordomo@localhost) by nsa.research.att.com (8.7.3/8.7.3) id QAA01697 for cfs-users-list; Tue, 14 Mar 2000 16:08:27 -0500 (EST)
X-Authentication-Warning: nsa.research.att.com: majordomo set sender to owner-cfs-users@nsa.research.att.com using -f
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 QAA01693 for <cfs-users@nsa.research.att.com>; Tue, 14 Mar 2000 16:08:25 -0500 (EST)
Received: by mail-blue.research.att.com (Postfix)
id 060794CE14; Tue, 14 Mar 2000 16:09:07 -0500 (EST)
Delivered-To: cfs-users@research.att.com
Received: from lila.ip.idiom.com (lila.ip.idiom.com [216.240.40.38])
by mail-blue.research.att.com (Postfix) with ESMTP
id 172E84CE0F; Tue, 14 Mar 2000 16:09:06 -0500 (EST)
Received: from Matador (localhost [127.0.0.1])
by lila.ip.idiom.com (8.9.1b+Sun/8.9.1) with SMTP id NAA18531;
Tue, 14 Mar 2000 13:17:10 -0800 (PST)
Message-ID: <042a01bf8df9$757c3270$8000000a@Matador>
From: "Bill Dorsey" <dorsey@lila.com>
To: "Steven M. Bellovin" <smb@research.att.com>
Cc: <cfs-users@research.att.com>
References: <20000314203229.1D8BC41F16@SIGABA.research.att.com>
Subject: Re: cfs and list status
Date: Tue, 14 Mar 2000 13:08:33 -0800
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.5600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600
Sender: owner-cfs-users@research.att.com
Precedence: bulk
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.
One complaint I do have about Microsoft's current implementation of
EFS is that the public key cryptography uses 1K keysizes for everything
and this has not been parameterized. Although 1K may be sufficient for
most purposes today, it would seem inadequate to protect data a few
years down the line if we expect Moore's law to continue to hold.
> The right way to do that is with a public key overlay on the existing CFS
> mechanisms. That is, use public key crypto to permit access to the data
> encryption key. You don't need to change CFS itself to do that.
>
Sure. This is how Microsoft has implemented EFS. For each file that is
encrypted, they generate a random session key. That session key is then
encrypted with the public key of (a) the user who created the key, (b)
the specified data recovery agent, and (c) if multiple users are allowed
access to the key, then the session key is encrypted with each of their
public keys. These encrypted session keys are then stored along with
the encrypted contents of the file on the disk (along with other attributes,
I'm sure).
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.
- Bill Dorsey
