[74] in The Cryptographic File System users list
Re: Keyfile
daemon@ATHENA.MIT.EDU (Rob Stampfli)
Mon Apr 27 21:46:10 1998
From owner-cfs-users@research.att.com Tue Apr 28 01:46:10 1998
Return-Path: <owner-cfs-users@research.att.com>
Delivered-To: cfs-mtg@bloom-picayune.mit.edu
Received: (qmail 16737 invoked from network); 28 Apr 1998 01:46:09 -0000
Received: from unknown (HELO rumor.research.att.com) (192.20.225.9)
by bloom-picayune.mit.edu with SMTP; 28 Apr 1998 01:46:09 -0000
Received: from research.att.com ([135.207.30.100]) by rumor; Mon Apr 27 21:41:35 EDT 1998
Received: from amontillado.research.att.com ([135.207.24.32]) by research-clone; Mon Apr 27 21:43:27 EDT 1998
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 VAA00035;
Mon, 27 Apr 1998 21:43:24 -0400 (EDT)
Received: (from majordomo@localhost) by nsa.research.att.com (8.7.3/8.7.3) id VAA11731 for cfs-users-list; Mon, 27 Apr 1998 21:40:55 -0400 (EDT)
X-Authentication-Warning: nsa.research.att.com: majordomo set sender to owner-cfs-users@nsa.research.att.com using -f
Received: from research.att.com (research-clone.research.att.com [135.207.30.100]) by nsa.research.att.com (8.7.3/8.7.3) with SMTP id VAA11720 for <cfs-users@nsa.research.att.com>; Mon, 27 Apr 1998 21:40:51 -0400 (EDT)
Received: from elektro.cmhnet.org ([192.188.133.3]) by research-clone; Mon Apr 27 21:41:27 EDT 1998
Received: from colnet by elektro.cmhnet.org with uucp
(Smail3.1.29.1 #1) id m0yTzO6-00008CC; Mon, 27 Apr 98 21:40 EDT
Received: by colnet.cmhnet.org (Smail3.1.28.1 #4)
id m0yTz9A-0008F9C; Mon, 27 Apr 98 21:25 EDT
Message-Id: <m0yTz9A-0008F9C@colnet.cmhnet.org>
Date: Mon, 27 Apr 98 21:25 EDT
From: res@colnet.cmhnet.org (Rob Stampfli)
To: cfs-users@research.att.com, john@interlog.com
Subject: Re: Keyfile
Sender: owner-cfs-users@research.att.com
Precedence: bulk
In recent email John writes:
>I was reading the documentation for a DOS encrypted filesystem
>product, and it had a feature I found interesting, and wondered if it
>would make sense in CFS.
... idea of key-file described ...
I believe newer versions of cfs already have this -- it is called the ..k
file and it is created in the top level of the encrypted directory at the
time the directory is created, unless the option is given to cmkdir to make
an old-style directory. The ..k file contains 32 bytes of data which map
the password you select to an internal password vector which is then used
to encrypt the contents of the directory hierarchy. Its purpose is to
permit you to change the password on a directory. However, if you remove
the ..k file, you have rendered the entire directory unreadable just as
surely as if you removed each individual file. (or perhaps "echo xyzzy >..k;
sync" to guarantee no one ever recovers this file, but I digress.)
If you would like to relocate the file somewhere else, I believe you can
do so -- just create a symbolic link in its place which points to where
the file resides.
If you happen to relocate the file to a floppy disk, you have created a
key disk, and both the disk and your password are now required to decrypt
the corresponding directory. (I haven't tested it, but I doubt you can
just "cat ..k >/dev/floppy"; you'd probably have to make a file system
on the floppy, mv the file to the floppy filesystem and make sure the
file system was mounted each time you wanted to do the cattach.)
Anyway, hope this helps, or at least provides some food for thought among
the readership of this list.
--
Rob Stampfli rob@colnet.cmhnet.org The Bill of Rights: It was a
614-864-9377 HAM RADIO: kd8wk@w8cqk.oh good thing while it lasted...
