On 05/25/2011 09:36 AM, Edward Shishkin wrote:
The goal of my work was:
1) to enhance existing encryption translator with algorithms, which
don't cause inflation of ciphertext, to avoid the end-of-file problem
specific to stackable file systems, which don't actually have
possibilities to keep extra-data (except extended attributes).
2) to resolve the problem of local data obsolescence, specific for
stackable file systems (the problem is described in details here:
http://www.mail-archive.com/gluster-devel@nongnu.org/msg07218.html )
3) to make the code extremely clear and well-commented.
In order to resolve these problems I have reviewed encryption means
currently provided by openssl package and have chosen the AES cipher
algorithm with the 3 cipher modes (CFB, OFB, and CTR) which satisfy
the property (1) above.
This is largely the same set of ciphers/modes represented by the current
(AES-branch) code, arrived at for basically the same reasons as Edward
describes. EOF (and to a lesser extent oddly-aligned holes elsewhere in
the file) are a fundamental problem with file-level encryption.
Also I have classified (see glossary in the code for the definition)
all those modes:
. atomic (CFB, OFB), which have the problem (2) above; . non-atomic
(CTR), which don't have the problem (2) above.
I assume you merely reversed the terms above (vs. how they're used
below) since it would seem that "atomic" modes are the ones that do
*not* have problem #2.
Encryption translators, which implement non-atomic cipher modes are
supposed to work on the client side to provide better scalability.
Encryption translators, which implement atomic cipher modes should
work on the server side as they need special serialization means to
avoid the problem (2) above. (Such serialization means don't work on
the client side).
Server-side encryption is unusable for CloudFS, as it requires trust of
the servers and that violates a fundamental aspect of the protections
CloudFS (compared to GlusterFS without it) is supposed to provide. We
do need to handle the concurrent-write race you mention, but we must do
so without keys on the server side. That means we can have the server
help with synchronization/coordination, but not with the
encryption/decryption itself.