[OpenAFS-devel] Re: [GSoC 2010] Encrypted storage

Tom Keiser tkeiser@sinenomine.net
Wed, 24 Mar 2010 16:29:22 -0400


On Wed, Mar 24, 2010 at 3:59 PM, Andrew Deason <adeason@sinenomine.net> wro=
te:
> On Thu, 25 Mar 2010 00:54:47 +0530
> Sanket Agarwal <sanket@sanketagarwal.com> wrote:
>
>> =A0 =A0- As we're looking for a fresh implementation[rather
>> =A0 =A0protocol/algorithm] for encryption various choices[encryption] ca=
n
>> =A0 =A0be provided to the user. It should be mapped to a configurable
>> =A0 =A0parameter/switch. OpenSSL would be the way to go!
>
> Simon or someone else can feel free to correct me... but you need to be
> doing this in the kernel[0], which rules out OpenSSL (as I understand
> it). The only feasible options I remember being discussed were Heimdal's
> hcrypto or something in-tree like Marcus' k5ssl.
>
> Although neither of those things are currently in the OpenAFS build
> system for you to use, if you start looking at those APIs, it's going to
> look a lot more similar to the real thing than if you're looking at
> OpenSSL.
>
> [0] It is technically possible to do the encryption in user-space, if
> you call out to a userspace binary like we do for afsdb lookups. In the
> long run, that approach becomes infeasible... but in the short term for
> GSoC I wonder if that's good enough? If you went that way, that part of
> the project would need to be re-done later to be in kernelspace, but I
> wonder if the rest of the project would still be worthwhile, then.
>

I think a great deal of value could come out of the design of a thin
abstraction that would allow us, over time, to back the crypto
routines with whatever is available.  Many kernels provide an
in-kernel crypto API; many of these can do hardware offload.  Once we
have a good API for the CM code to call, it's perfectly reasonable
(and perhaps even preferable from a portability standpoint) to make
the first implementation of our API a userspace upcall to e.g.
OpenSSL, or a pkcs11 library.  We can always revisit the issue later
and provide targeted in-kernel implementations of the API on platforms
where people care enough to do the work.

-Tom