On 05/24/2011 11:00 PM, Jack Rieden wrote:
Please help me understand why you feel the need to add your version
of crypto for cloudfs. Granted I haven't reviewed the source, but I
see aes signatures ..
There are a host of reasons why you should not be adding your own
crypto to a feature/component. The general rule is 'don't do it'.
Encryption - both on the network and on disk - is one of the core
features of CloudFS. The network encryption is off-the-shelf OpenSSL,
so I don't think that should be very controversial. What Edward was
asked to do was improve the on-disk encryption, which for CloudFS needs
to have three features:
(1) Integrate with the GlusterFS data path, to avoid excessive
performance loss e.g. due to context switches or copies between the
GlusterFS daemons and those handling the encryption. (This rules out
things like encfs/ecryptfs over GlusterFS).
(2) Properly handle concurrent overlapping writes from multiple clients.
(3) Don't trust servers. In the environments for which CloudFS is
targeted, servers may not be trusted to do anything but store and later
return encrypted data - and sometimes not even that. In particular,
they may not *ever* be trusted with encryption keys. This rules out
volume-level encryption on the server.
AFAIK there are no existing solutions that meet these requirements,
hence the new code. Note that I haven't looked to see whether Edward's
code actually meets these requirements (especially #3) but that's the
short explanation of why CloudFS has its own encryption.