[OpenAFS-devel] [GSoC 2010] Encrypted storage

[Simon Wilkinson]

Hi, and thanks for your interest in OpenAFS

On 23 Mar 2010, at 16:48, Sanket Agarwal wrote:
> 	=95 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]
*) 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.

> 	=95 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. =
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.

> 	=95 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.=