On 05/24/2011 07:46 PM, Edward Shishkin wrote:
Hello everyone.
This is only for review/comments.
Hi Edward,
Do you have an overall design document for how this fits into cloud & cloudfs?
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 :(
thanks!
Ric
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.
Thanks,
Edward.