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? _______________________________________________ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community