Re: Tramp and crypted files

[Deus Max]

On Mon, May 25 2020, Michael Albinus wrote:

> 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).
>
OK.

> - 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.
>
Good.

>   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 ...".
>
EncFS is not needed for the this setup. Vanilla gpg encryption could be
used for the above. Without hidding the filename (with .gpg extension).
only encrypt the content.

EncFs adds file name encryption and obsfucation, making in hard to guess
the encrypted file, even if you know the file name. So you have to
temporarily mount somewhere, in order to see the decrypted filenames.

> - 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.
>
Yes, the .encfs6.xml is very importantf for EncFS.
I think encfs needs a temprorary mount point, to function. This can be a
weakness in a network situation, as any interruption could leave the
files open or in a strange state, inviting the case to be compromised.

>   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.
>
Correct me if I'm wrong, but I don't think the webdav protocol behaves
well for multi-user editing. It simple saves the last edit. without
comparing for merge conflicts. It is a last save takes all.
For access from different hosts, the user should take care to use strict
sequential access.

DeusMax