Re: Tramp and crypted files

[Michael Albinus <michael.albinus@gmx.de>]

Deus Max <deusmax@gmx.com> writes:

Hi,

>> As written in my other messages, I don't believe (anymore) we shall mix
>> the en-/decryption part with Tramp implementation. This shall be
>> implemented in another file name handler, working over local
>> files. Tramp with whatever backend would be responsible then for copying
>> the encrypted files from/to the remote side.
>
> Agree.
> Encfs handles the encryption.
> The actual files are encrypted, encfs defines a mount-point where the
> files are displayed decrypted.
>
> Having an easy to use Tramp method for encrypting cloud data would be a
> good plus for privacy.

I have played with encfs and your script as well as with first snippets
of a Tramp implementation. Just for discussion, here are my conclusions
so far:

- Encryption of files and file names shall be possible for *every*
  remote connection. This means, that the approach will be different
  from what you have done in your script (where you work over webdav
  based cloud servers).

- Encryption of files and file names shall be separated from vanilla
  Tramp. It is optional, and a user must enable it explicitly for a
  given remote directory. This is because of performance, and because of
  implementation simplicity. As a result, there shall be almost no
  change of existing Tramp; all encrytion functionality will be
  cumulated in a new tramp-crypt.el file.

  Of course, encryption can be activated for several remote directories
  in parallel. But they must not be subdirectories of each other.

- As a consequence, there will be an additional file name handler, which
  reacts on the same file name syntax as Tramp. It is arranged to be
  called before the vanilla Tramp file name handler. All of its
  functions will check, whether a user has activated encryption for a
  given remote directory. In that case, if an argument of a function is
  a file name which belongs to such a directory, that file name will be
  transformed into its crypted counterpart, and the native Tramp file
  name handler is activated for this function with encrypted file
  names. If the function returns file names, the reverse action is
  applied: if a file name is encrypted, the result will be adapted to
  contain the corresponding decrypted file name.

- For file copying, the file itself is either encrypted (when copying
  to remote) or decrypted (when copying from remote). Together with the
  encryption/decryption of the file name, the copy operation will be
  applied by vanilla Tramp operation.

- There will be *no* mounted encfs file system. File name
  encryption/decryption will be performed by "encfsctl encode ..." and
  "encfsctl decode ..." process calls. File encryption happens via
  "encfsctl cat ..." and "encfsctl cat --reverse ...".

- The local rootdir of a crypted remote directory will be created temporarily
  when needed. It is always rearrangeable via its config file
  .encfs6.xml, which contains the filesystem information. Only this
  config file will be kept persistently, one file per activated crypted
  remote directory, somewhere in ~/.emacs.d/. Optionally, it will be
  kept also in the crypted remote directory as well.

  With this, encrypted files from remote can be accessed by different
  Emacs sessions running from different host, by different users. All
  what they need to know is the remote directory name (in Tramp syntax),
  and the password the encryption/decryption is protected with. That's
  what "cloudy servers" are good for.

Comments?

> DeusMax

Best regards, Michael.