On 05/25/2011 02:40 AM, Ric Wheeler wrote:
On 05/24/2011 07:46 PM, Edward Shishkin wrote:
> Hello everyone.
> This is only for review/comments.
Do you have an overall design document for how this fits into cloud &
Yes, of course.
In accordance with the "todo" documentation provided by Jeff Darcy,
transparent encryption is an important component of CloudFS
functionality, which is a layer over the distributed file system
CloudFS is implemented as a set of so-called translators, and
transparent encryption is also supposed to be implemented as
translators of special "encryption" type. It can be considered
as a layer which "listens" the following "ports":
and, in particular, performs encryption/decryption transforms.
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:
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.
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.
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).
I have reviewed the NIST recommendations and have implemented the
counters and initial vectors for mentioned modes in accordance with
these recommendations. (The format of counters and initial vectors
are strictly defined in the comments).
We should also review this with our internal security team (Jack and his
people) since we have a heavy weight process that needs to be done for
anything crypto related :(
I am with both hands for the collaboration,
let me know if you need more details.
> Common comments:
> Format of counters is:
> . high 64 bits are minor object id (this is
> gfid transformed by 64-hash);
> . low 64 bits are an offset in a file;
> Format of initial vectors:
> for OFB mode IV is a counter;
> for CFB mode IV is a counter, encrypted with
> respective cipher key.
> For non-atomic cipher modes there is no problem of local data
> obsolescence. For such modes the crypt translator is supposed
> to work on the client side.
> For atomic modes the crypt translator is supposed to work on
> the server side instead of oplock translator. The problem of
> local data obsolescence is resolved by serialization via special
> mutex in the struct _inode that should be introduced instead of
> generation counter.