On Wed, Mar 24, 2010 at 3:59 PM, Andrew Deason <[email protected]> wrote: > On Thu, 25 Mar 2010 00:54:47 +0530 > Sanket Agarwal <[email protected]> wrote: > >> - 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! > > 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 _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
