[OpenAFS-devel] [GSoC 2010] Encrypted storage

Thu, 25 Mar 2010 00:54:47 +0530

--001485f90f522b0cda048290e236
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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 th=
e
   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 th=
e
   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 accessin=
g a
   file just because it is *huge*. In a sense we'll have to restrict oursel=
ves
   to Block Ciphers. But that I think will be the obvious choice anyways. A=
lso
   my "Concurrent" mind tingles... if encryption could violate present
   assumptions about consistency.

On Tue, Mar 23, 2010 at 11:16 PM, Simon Wilkinson <sxw@inf.ed.ac.uk> wrote:

> 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 us=
ed
> 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 t=
o
> 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 ser=
ver
> side encryption scheme - all of the encryption and decryption work would =
be
> performed by the client. The purpose is to prevent the server from knowin=
g
> 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 th=
e
> 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 additiona=
l
> 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 ?

>
> >       =95 Also, a design needs to be worked out in order to allow selec=
tive
> data sharing through management of user/data keys. I will go through the
> documentation of OpenAFS to suggest a solution, but pointers/help is grea=
tly
> 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 th=
is
> 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.

--001485f90f522b0cda048290e236
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Guys, First of all a thumbs up for replying! It is really great t=
o see some excellent help! I have been busy reading the docs about O=
penAFS[ 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. 
 <ul><li>I&#39;ll need to dig into the Cache Manager[CM] which currently=
 manages the locally managed cache of the user. In order to implement the c=
lient side encryption atleast CM will have to be augmented. </li><li>
As we&#39;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 w=
ay to go! 
</li><li>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&#39;ll have to restrict our=
selves to Block Ciphers. But that I think will be the obvious choice anyway=
s. Also my &quot;Concurrent&quot; mind tingles... if encryption could viola=
te present assumptions about consistency. 
</li></ul> <div class=3D"gmail_quote">On Tue, Mar 23, 2010 at 11:16 PM, =
Simon Wilkinson &lt;<a href=3D"mailto:sxw@inf.ed.ac.uk">s=
xw@inf.ed.ac.uk</a>&gt; wrote: <blockquote class=3D"gmail_quote" =
style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8=
ex; padding-left: 1ex;">
Hi, and thanks for your interest in OpenAFS 
 
On 23 Mar 2010, at 16:48, Sanket Agarwal wrote: 
&gt; =A0 =A0 =A0 =95 Where can I learn about the present encryption methodo=
logy 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 goo=
d way to do Server side encryption!

We&#39;d be doing this separately from OpenAFS&#39;s current (and future) w=
ire encryption protocols. As I&#39;d envisaged the project, it&#39;s not re=
ally a server side encryption scheme - all of the encryption and decryption=
 work would be performed by the client. The purpose is to prevent the serve=
r 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&#39;s key, and stores encrypted key in fil=
e&#39;s metadata [0] </blockquote><div>I am not very clear about how do =
you plan to store metadata. What I understood is that metadata shall contai=
n the file information[file metadata] bundled with the key. Is such metadat=
a handled in some way in OpenAFS ? Also if not which module shall be respon=
sible for managing it, Client Side ? 
</div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb=
(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
*) Client stores file on file server 
=A0</blockquote><blockquote class=3D"gmail_quote" style=3D"border-left: 1px=
 solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Reading would work in reverse of this operation - as you can see, all of th=
e cryptography is done at the client (in the cache manager). The server is =
unmodified - it just saves blobs of data. 
 
[0] AFS doesn&#39;t currently have proper extended attributes support, so f=
or the purposes of this project we&#39;d fake metadata, by creating an addi=
tional file for each encrypted file, containing the set of keys. The intent=
ion would be that at some later date this would be folded into extended att=
ributes. 
</blockquote><div>Just curious, what has been the progess on implementing e=
xtended attributes ? pointers ? </div><blockquote class=3D"gmail_quote"=
 style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.=
8ex; padding-left: 1ex;">

&gt; =A0 =A0 =A0 =95 Also, a design needs to be worked out in order to allo=
w selective data sharing through management of user/data keys. I will go th=
rough 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 impleme=
nting single user support will likely take up most of the summer. </blockqu=
ote><div>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.=A0 
</div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb=
(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">If the user=
&#39;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 t=
o read it. Managing these public keys beyond this is out of scope for this =
project. 
 
&gt; =A0 =A0 =A0 =95 Who&#39;ll be likely mentoring this project, it&#39;ll=
 be helpful if I can address the demands of the mentor as he would know the=
 requirements best! 
 
We haven&#39;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.</blockquote></div>

--001485f90f522b0cda048290e236--