Edward,
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'.
Please let me know a good time we can talk about this,
and I'll ask some of our crypto engineers to join
the conversation to help see how we can find alternatives.
thanks,
jack
----- Original Message -----
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.