On Thu, 2004-01-22 at 11:31, Michael Halcrow wrote: > If you could have any feature that you wanted in an encrypted > filesystem, what would it be?
I get to dream here? I want an easy and clean API to discover if a filesystem is encrypted. I don't consider ioctl to be easy or clean. Bonus points for making it portable and easy to fit into a posix system. I want is something my mother could use to keep her files safe. If the box is her's, I want to be able to setup an encrypted filesystem during install. Basic stuff like mounting should have a friendly GUI with prompt. But my mother shouldn't have to know what mounting is. If the filesystem isn't critical, the system shouldn't block waiting for a password. Rather, if it has been configured to be mounted on boot but a password isn't entered during the boot process, something like D-Bus should be used to request the password the first time she tries to access the encrypted filesystem. I want something that users can use without administrator intervention. A user should be able to encrypt their entire home directory, or a directory underneath it. Any program she runs should be able to interact with that directory as if it were normal. See the comment about prompting for a password the first time the directory is used. My mother shouldn't have to worry about permissions. If she has an encrypted directory, only her programs should be able to see it's contents. Not even root should be able to see it necessarily. She should be able to associate other users (with passwords different from her own) with the encrypted directory. They should also be able to interact with the directory after going through their own "mount" step. This could possibly be accomplished like this: My mother has a public/private key pair that is password protected. Possibly stored in something like /etc/shadow. The directory is encrypted with a symmetric key. Near the beginning of the "directory" is a copy of the symmetric key for the directory encrypted with her public key. After my mother is prompted for her password (seperate from her login password, to reinforce the fact that this is a higher security level), the private key is decrypted and used to get the symmetric key. When she decides to give me access, she encrypts the symmetric key (which she already knows as a result of the mount) with my public key and appends it to the ACL for the directory. Encrypted directories should look just like files before being mounted so that that can be easily transferred between systems. It should be possible to store them on systems that knows nothing about the format without losing any data. (No hiding stuff in forks.) It should be easy to transfer public/private key pairs between systems without knowing about dot directories, etc. A nice "I'm Moving" gui should be available. It should be possible to associate multiple key pairs with an account. Because this is going to have to be kernel level, there should be a _very_ standard location like /etc/passwd for the key pairs. If multiple key pairs are registered, it should be easy to tell which one I'm unlocking so I can remember the password I chose for it. Of course, no sensitive data should ever be swapped. To prevent pinning giant pages of data, only the symmetric keys should be on non-swappable pages. I shouldn't have to pay a performance hit for most of the disk cache being encrypted. (Okay, so maybe I'm dreaming a little too big now.) That should keep you busy for awhile. -- Stuart Jansen <[EMAIL PROTECTED], AIM:StuartMJansen> âThe programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.â -- Fredrick Brooks, Mythical Man Month
signature.asc
Description: This is a digitally signed message part
____________________ BYU Unix Users Group http://uug.byu.edu/ ___________________________________________________________________ List Info: http://uug.byu.edu/cgi-bin/mailman/listinfo/uug-list
