Comment 6 for bug 376580

Dnia 2009-05-14, czw o godzinie 18:17 +0000, Witold Baryluk pisze:
> Dnia 2009-05-14, czw o godzinie 17:54 +0000, Tyler Hicks pisze:
> > Can you elaborate on what random data in the header are you talking
> > about? Each file has a unique file encryption key (FEK) that is
> > encrypted with your mount key and stored in the header. As long as you
> > have your mount key, you will be able to decrypt the encrypted FEK and
> > then decrypt the file contents. Is that the random date you were
> > referring to?
> >
>
> Yes, exactly this random data.
>
> Generally if it will be used for backup we would want to encrypt lowfs
> to the predictable (but still in some secret way) content in highfs, so
> only incremental data will be needed to send over network and stored on
> server. If every reboot or remount of such reverse ecryptfs FEK will
> change, then it will be impossible to easily check if files really
> changed (we can first check metadata, but still ie. rsync check content
> of file wen metadata disagree, so still only delta are send, ie. when
> only single block was changes, or data was appended to it).

Some new thoughts...

Ok, anyway I see this will not work so easly. It will work on append or
single block change. But it will fail for adding or removing data inside
of file. All data beyond this removed/added blocks will need to be sent
over network. Not completly efficient like orginal rsync, but secure and
should just work. Any way, even when only part of file changed and we
need send whole file, this isn't very big problem. Only small percentage
of files on big file system changes actually, and if they change they
mostly changes completly.

This is exactly the same way when synchronising normal ecryptfs lowfs,
so still "reverse" mode can be usefull.

There is tool which mitigates this problem: rsyncrypto. It keeps locally
enrypted copy of files, and synchronises them in effective way (only
what was changed, added or removed). It does this be interesting mode
of encryption. Modified CBC mode.

http://rsyncrypto.lingnu.com/index.php/Algorithm

Unfortunetly i think CBC mode (particulary modified version of it),
isn't very secure.

BTW. In which mode ecryptfs operates? CTR?

Ok, i see it is more complicated ;)

Going to read
ecryptfs.sourceforge.net/ecryptfs_design_doc_v0_1.pdf

--
Witold Baryluk