On 05/25/2011 03:48 PM, Jeff Darcy wrote:
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.
Nop, everything is correct:
* block (atom) A logical unit in a file. A minimal chunk of
* file's data (plain-text[cipher-text]) that will
* be involved to encryption[decryption] process.
* Atom size depends on cipher algorithm, mode, etc.
* If atom size is more than 1 bit, then we'll say
* that mode is atomic. Otherwise it is inatomic.
So, "atomic" means that transform is going by "atoms", i.e.
read-modify-write are required and welcome to the 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.
Why? IMHO Key server is a rather popular thing.
It can be implemented in various trusted centres
like commercial banks, notaries, etc.
That means we can have the server
help with synchronization/coordination, but not with the
encryption/decryption itself.
Queues to perform read-modify-write on the server side is
a vary complicated thing, whereas I guess all the crypto
stuff should be very simple..
Edward.