Comment 7 for bug 376580

Dnia 2009-05-16, sob o godzinie 18:50 +0000, Witold Baryluk pisze:
> 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.
> >

> Some new thoughts...

Was thinking more about FEKs and FNEKs.

I think i found general and flexible solution:

1. mount plain filesystem in reverse mode
2. start user space daemon which will be asked for FEKs of this files.
   - it can open already (possibly remote) encrypted file, read header
     and use the same FEKS (they can be locally, they can be on sshfs,
      anywhere, or download it using rsync or anything)
   - or it can maintain local copy of headers (which is safer, because
     remote server can change headers to something easier to crack).
      - in standard files (but with only header)
      - or in DB (sqlite or Berkley DB)
   - or provide the same FEK or some deterministic function of available
     informations (like file name + private key)
3. kernel space will ask for this FEKs, and use them for encryption,
   preferably in ECB or CTR mode, so rsync will be quite happy.
4. additionally kernel will not ask for this keys if this file isn't
   going to be opened (rsync for example first check modification time)
   Maybe only FNEK will be needed to ask, so we will know what filenames
   to give to opendir()

The last point can be optimised to allow asking for multiple keys,
(reducing context switches). This also makes kernel part simple.

Part of this infrastructure is already present in ecryptfsd, right?

--
Witold Baryluk