1995-10-28 - Re: New release of CFS Unix encrypting file system available

Header Data

From: Anonymous User <nobody@c2.org>
To: cypherpunks@toad.com
Message Hash: 9c09f3de5b49cbef50fdba77b2763f8bd59278f6a7f228a654b9265e6afda4b1
Message ID: <199510282012.NAA25761@infinity.c2.org>
Reply To: N/A
UTC Datetime: 1995-10-28 21:31:02 UTC
Raw Date: Sun, 29 Oct 1995 05:31:02 +0800

Raw message

From: Anonymous User <nobody@c2.org>
Date: Sun, 29 Oct 1995 05:31:02 +0800
To: cypherpunks@toad.com
Subject: Re: New release of CFS Unix encrypting file system available
Message-ID: <199510282012.NAA25761@infinity.c2.org>
MIME-Version: 1.0
Content-Type: text/plain


In article <199510271954.PAA20647@universe.digex.net>
Scott Brickner <sjb@universe.digex.net> wrote:
>Matt Blaze writes:
>>CFS pushes encryption services into the Unix(tm) file system.  It
>>supports secure storage at the system level through a standard Unix
>>file system interface to encrypted files.  Users associate a
>>cryptographic key with the directories they wish to protect.  Files in
>>these directories (as well as their pathname components) are
>>transparently encrypted and decrypted with the specified key without
>>further user intervention; cleartext is never stored on a disk or sent
>>to a remote file server.  CFS employs a novel combination of DES
>>stream and codebook cipher modes to provide high security with good
>>performance on a modern workstation.  CFS can use any available file
>>system for its underlying storage without modification, including
>>remote file servers such as NFS.  System management functions, such as
>>file backup, work in a normal manner and without knowledge of the key.
>
>What happens to hard links?
>
>mkdir foo bar
>CFS_set_directory_key -directory ./foo -key foo-key
>CFS_set_directory_key -directory ./bar -key bar-key
>cp /etc/passwd ./foo/test1
>ln ./foo/footest ./bar/bartest
>cmp ./foo/footest ./bar/bartest

This is a serious flaw. The emperor has no clothes. People should
sue at&t for this shit.





Thread