Proposal: Personal Data Encryption (maybe SoC?)

Joe Pfeiffer jjpfeifferjr at comcast.net
Thu Mar 22 17:55:36 CET 2007


OK...  I'm clearly just not familiar enough with FUSE, since building
a 'personal encryption file system' looks like the way to go, and that
didn't occur to me right off.

So...  'pefs' maintains a per-user file with a table of encrypted
files and a hashed key for each file.  It also maintains, in-memory,
the current encryption keys if any (I don't especially like this, but
I don't see a way around it.  Oh, well, any program that deals with
keys and passwords has to have them in-memory at some point; this
system just keeps them around longer).

When a user attempts to read or write a file, pefs checks to see if it is
encrypted.  If it is, and there is no current encryption key whose
hash matches the file's encryption hash, it asks for the key.
Depending on the DISPLAY environment variable, this would either be by
a dialog or through getpasswd().  The key and its hash are kept
in-memory, and a configurable timer is set.

As long as the user keeps performing operations on encrypted files
using this key, the alarm keeps getting reset.  If a key's timer ever
expires, the in-memory key is erased (and the user will be prompted
for the key again on the next operation on an encrypted file).

Command-line programs are able to encrypt and decrypt files.  This
both performs the encryption (decryption), it also adds (removes) the
file from the encrypted file table.  A GUI encryption manager can be
built on top of these programs; a user has to go through a little
extra work to tell the system that a file should be encrypted, but
after that pefs manages the encryption with no more user annoyance
than necessary.  An encryption-aware gtk file chooser dialog would
have a "save encrypted" checkbox.

A user should also be able to optionally request an encryption key
check:  if the file is marked as using the check, the key entered by
the user is hashed and compared to the file's encryption key hash.  If
it doesn't match, the user is informed and prompted again (if this
check is not requested, the only clue the user gets that the wrong key
was entered is that reads return gibberish, writes fail, and a new key
is requested for every file operation).

One last wrinkle is that users can elect to simply use their passwords
as their sole encryption key (there have been a bunch of good
password-equivalent ideas floating about; let's assume that whatever
is used is something that can be translated to a string, which seems a
safe assumption).  If this option is taken, then when an encryption
key is requested it is passed off to the authenticator and only
accepted if it is in fact the user's password.  If a user's password
is changed, any encrypted files need to first be encrypted using
the new password, and then decrypted using the old one; the encryption
manager needs to be called from the password manager for this.  In
this case, no hashed per-file key has to be stored.

This last case above is assumed to be the common case, and should be
the default:  in this case, a user is simply able to mark a file as
"secret", and whenever they try to access the file (and haven't
accessed it within the last several minutes) get prompted for their
password.  The other options are available under an "advanced" menu.

Thoughts?




More information about the community mailing list