// COMPLETE THREAD

NT 5.0 and EFS -- A victory for widespread use of crypto?

5 expanded posts ยท every known parent and child

NODE bcd1e7a3NT 5.0 and EFS -- A victory for widespread use of crypto?
All,

Does anyone have any opinions on the encrypting file
system (EFS) that is supposed to ship with NT 5.0?

The white paper on the MSDN web site says it uses
DESX (no explaination as to what the X is) and an
RSA public key algorithm to store the symmetric keys,
which are random for each file.

So what's DESX?

EFS appears to have the architecture to support
arbitrarily long keys although this has been crippled
in the NT5.0 release, presumably because of
export limitations.  It has the key recovery features
you would expect in a commercial product of the
type; they can be turned off administratively.

Is this a victory for wider use of encryption?

--
Steve Dunlop
letters: "dunlop" at "bitstream" dot "net"
http://www2.bitstream.net/~dunlop
NODE b570d107Re: NT 5.0 and EFS -- A victory for widespread use of crypto?
> On Wed, Oct 07, 1998 at 06:06:21PM -0500, Steve Dunlop wrote:
> 
> So what's DESX?

DESX is DES with 'whitening' of input and output. See B. Schneier,
Applied Cryptography, 2nd ed., p.295.

M. K. Shen
NODE 1dcf1284Re: NT 5.0 and EFS -- A victory for widespread use of crypto?
On Wed, Oct 07, 1998 at 06:06:21PM -0500, Steve Dunlop wrote:

| The white paper on the MSDN web site says it uses
| DESX (no explaination as to what the X is) and an
| RSA public key algorithm to store the symmetric keys,
| which are random for each file.
| 
| So what's DESX?

DESX is where you xor the output of a des block with the key.  Has
some interesting properties which McCurley? showed in Crypto 97
proceedings.

Adam


-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume
NODE c1b549aaRe: NT 5.0 and EFS -- A victory for widespread use of crypto?
At 06:06 PM 10/7/98 -0500, you wrote:
>
>Does anyone have any opinions on the encrypting file
>system (EFS) that is supposed to ship with NT 5.0?

  you're asking the *cypherpunks list* if anyone has
an opinion?  oh, gad...  :-)


>EFS appears to have the architecture to support
>arbitrarily long keys although this has been crippled
>in the NT5.0 release, presumably because of
>export limitations.  It has the key recovery features
>you would expect in a commercial product of the
>type; they can be turned off administratively.


  excerpted (without permission) from the latest issue of the
microsoft systems journal, about the new feature of NTFS in
NT 5.0, specifically regarding encryption:

  "...NTFS has built-in recovery support so that the encrypted
   data can be accessed.  In fact, NTFS won't allow files to be
   encrypted unless the system is configured to have at least
   one recovery key.  For a domain environment, the recovery keys
   are defined at the domain controller and are enforced on all
   machines within the domain...."

  i'll definitely have to play with this one -- wh'appens if you add
a machine to a domain, encrypt some files, then remove the machine
from the domain?  can the admin of the domain recover all files
you encrypt from that point on?  and so on...


  "...For home users, NTFS automatically generates recovery keys
   and saves them as machine keys.  You can then use command-line
   tools to recover data from an administrator's account."


  if i were looking for a point of attack, i'd start with the
low-level key management here...


  another interesting thing to try: install NT on a workstation,
encrypt a removable disk, then reinstall NT on that workstation
again -- have you defeated key recovery for that disk?  (since the
machine keys for the first install of NT are presumably gone...)


-landon (re-lurking)
NODE 2a72b53cRe: NT 5.0 and EFS -- A victory for widespread use of crypto?
landon dyer wrote:

> At 06:06 PM 10/7/98 -0500, you wrote:
> >
> >Does anyone have any opinions on the encrypting file
> >system (EFS) that is supposed to ship with NT 5.0?
>
>
>   "...NTFS has built-in recovery support so that the encrypted
>    data can be accessed.  In fact, NTFS won't allow files to be
>    encrypted unless the system is configured to have at least
>    one recovery key.  For a domain environment, the recovery keys
>    are defined at the domain controller and are enforced on all
>    machines within the domain...."
>
>   i'll definitely have to play with this one -- wh'appens if you add
> a machine to a domain, encrypt some files, then remove the machine
> from the domain?  can the admin of the domain recover all files
> you encrypt from that point on?  and so on...

MSJ conflicts with the MS white paper in that, according to MS,you can
explicitly turn off key recovery at the domain level.  For
workstations not a part of a domain, key recovery can be turned
off at the local administrator level.

The domain setting overrides the local administrator setting
as long as the workstation is a member of a domain. So the
answer to your question, apparently, depends on the local
administrator's settings for the encryption policy.

>   "...For home users, NTFS automatically generates recovery keys
>    and saves them as machine keys.  You can then use command-line
>    tools to recover data from an administrator's account."
>
>   if i were looking for a point of attack, i'd start with the
> low-level key management here...
>

Their summary is somewhat simplified.  The key managementhas several
alternatives with the usual tradeoffs between
security and convenience.  The private key for recovery can
be stored on a floppy, encrypted using a passphrase, or
for that matter can be destroyed.

>   another interesting thing to try: install NT on a workstation,
> encrypt a removable disk, then reinstall NT on that workstation
> again -- have you defeated key recovery for that disk?  (since the
> machine keys for the first install of NT are presumably gone...)
>
> -landon (re-lurking)

Yes, if you are using self-signed certificates they are
generated randomly during each install.

--
Steve Dunlop
letters: "dunlop" at "bitstream" dot "net"
http://www2.bitstream.net/~dunlop