On 3/31/2010 3:56 AM, Sanket Agarwal wrote: > > > On Wed, Mar 31, 2010 at 12:21 PM, Sanket Agarwal > <[email protected] <mailto:[email protected]>> wrote: > > Simon would be a better person to what should and what should not be > a part of the GSoC proposal. But, as of now I think it should be > deferred.
If the result of this project is meant to be an architectural change to the OpenAFS cache manager then by all means the full membership of this list has the right to propose suggestions and discuss their concerns. However, it must be kept in mind that this project proposal is for a GSoC project and as such the scope must be reasonable. Simon, as the person that proposed the project, should be the one to explain what his intentions were with regards to the GSoC goals. > The first thing for the project would be to integrate HCrypto into > OpenAFS and provide an API for future use at a Kernel Level. As > Simon envisions, it is necessary to put the Crypto API into at the > Kernel level rather than using rich User Mode libraries like OpenSSL > etc, which can be used at the Client[ Cache Manager ] side. I suspect that this work has already been done by Simon as part of the rxgk work. I do not think this should be in scope for a GSoC project. > The second task would be to get the Encryption Layer working. > File encryption would be targeted as of now. In order to encrypt the > Directory Structure, server's support shall be necessary. As I have > to technically complete the stated project within 3 months( I will > obviously continue to contribute :) ), I cannot form astronomical > proposals! Spenser Olsen replied in another response to this thread that he believes that EncFS would provide equivalent functionality to this proposed project when overlaid on top of /afs. In a sense, EncFS is an excellent comparison to this project proposal. The functionality is essentially the same. The difference is that EncFS, being a FUSE file system, is only available on a subset of the platforms that OpenAFS supports. One of the strengths of OpenAFS is that once data is stored on Linux it can also be accessed or modified on Solaris, Windows, MacOS, and many other file systems. One way of describing this project would be to implement EncFS as part of the OpenAFS cache manager. If the goal of this project was to eventually produce a broader cross-platform multi-user key management system, then I think that architecture work would have to be developed and agreed to by the community before a portion of its implementation can be submitted as a GSoC project. That is of course assuming that the goal of the project is code that will be integrated into a future stable OpenAFS release within a year. If the goal is to produce a working prototype so that the community can gain some experience developing such a solution, then I believe going ahead with this project in GSoC is not a problem. As with all GSoC projects, we hope the end results of the project will be usable code that can be integrated. My biggest concern is ensuring that whatever is implemented as part of the OpenAFS Unix cache manager can eventually be implemented on Windows or other platforms that do not make the same internal assumptions. I would also like to ensure that the encryption functionality would be optional. Perhaps loaded at run-time. As a result, I would like to see the design be two components: * First, develop an abstraction layer that sits within the Unix cache manager but logically above the cache manager. * Second, an implementation of an encryption layer module that plugs into that interface. There are several benefits to this approach. First, separating the encryption layer from the cache manager layer allows the encryption layer's assumptions about block size to be independent from the cache manager's assumptions about chunk size. Second, the abstraction layer is something that in theory can be shipped as part of a future OpenAFS much sooner than a full encryption layer. Third, such a layer permits different encryption layers to be experimented with without further modifications to the cache manager implementation. Finally, if implemented correctly, the encryption layer should be highly portable permitting it to be reused in other cache manager implementations. A beneficial side effect of such a design is that the contents of the cache will be encrypted in exactly the same way as on the file server. An attacker will not be able to read unencrypted data out of the cache files. Jeffrey Altman Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
