Hi Guys, First of all a thumbs up for replying! It is really great to see some excellent help!
I have been busy reading the docs about OpenAFS[ and it has been a treat ] from cgi-bin/cvsweb.cgi/openafs/doc/pdf/. Through the literature survey I have sketched some of the facts that could be starting point of my work. - I'll need to dig into the Cache Manager[CM] which currently manages the locally managed cache of the user. In order to implement the client side encryption atleast CM will have to be augmented. - As we're looking for a fresh implementation[rather protocol/algorithm] for encryption various choices[encryption] can be provided to the user. It should be mapped to a configurable parameter/switch. OpenSSL would be the way to go! - I am a bit curious about the part of CM where it actually caches a *part* of say a big file, so that a user is not restricted from accessing a file just because it is *huge*. In a sense we'll have to restrict ourselves to Block Ciphers. But that I think will be the obvious choice anyways. Also my "Concurrent" mind tingles... if encryption could violate present assumptions about consistency. On Tue, Mar 23, 2010 at 11:16 PM, Simon Wilkinson <[email protected]> wrote: > Hi, and thanks for your interest in OpenAFS > > On 23 Mar 2010, at 16:48, Sanket Agarwal wrote: > > • Where can I learn about the present encryption methodology used > in OpenAFS for packet encryption and which module shall have the relevant > code section ? This can give me an insight about what can be a good way to > do Server side encryption! > > We'd be doing this separately from OpenAFS's current (and future) wire > encryption protocols. As I'd envisaged the project, it's not really a server > side encryption scheme - all of the encryption and decryption work would be > performed by the client. The purpose is to prevent the server from knowing > any of the content uploaded by the client. > > The workflow would be as follows: > > *) User writes a file locally > *) Client generates a key for the file, and encrypts file with it > *) Client encrypts key with user's key, and stores encrypted key in file's > metadata [0] > I am not very clear about how do you plan to store metadata. What I understood is that metadata shall contain the file information[file metadata] bundled with the key. Is such metadata handled in some way in OpenAFS ? Also if not which module shall be responsible for managing it, Client Side ? > *) Client stores file on file server > Reading would work in reverse of this operation - as you can see, all of the > cryptography is done at the client (in the cache manager). The server is > unmodified - it just saves blobs of data. > > [0] AFS doesn't currently have proper extended attributes support, so for > the purposes of this project we'd fake metadata, by creating an additional > file for each encrypted file, containing the set of keys. The intention > would be that at some later date this would be folded into extended > attributes. > Just curious, what has been the progess on implementing extended attributes ? pointers ? > > > • Also, a design needs to be worked out in order to allow selective > data sharing through management of user/data keys. I will go through the > documentation of OpenAFS to suggest a solution, but pointers/help is greatly > appreciated. > > This is a much later part of the project. My suspicion is that just > implementing single user support will likely take up most of the summer. Yep given the code base and tough coding standards I would prefer to contribute consice functionality with excellent code THAN promising you to *change the world* :D. > If the user's key is a public key pair, then we can simply do this by > just encrypting the file key with keys for every user that should be able > to read it. Managing these public keys beyond this is out of scope for this > project. > > > • Who'll be likely mentoring this project, it'll be helpful if I > can address the demands of the mentor as he would know the requirements > best! > > We haven't quite sorted out mentoring assignment, but I suggested this > project originally. There are many people on this list who will be happy to > help too! > > Cheers, > > Simon.
