[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Tramp and crypted files (was: What is the most useful potential feature

From: Michael Albinus
Subject: Tramp and crypted files (was: What is the most useful potential feature which Emacs lacks?)
Date: Mon, 18 May 2020 10:05:18 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Richard Stallman <address@hidden> writes:

> Since we can't determine whether any given user will want the
> auto-encrypt-decrypt, we should let users specify yes or no.
> Eventually we might develop ideas for defaults more sophisticated
> than just "yes" and "no".

As I said the other thread, we could create a new connection method
"nextcloud-crypt" which does the job. A user could decide whether she
uses "nextcloud" or "nextcloud-crypt" when accessing a given file. This
could happen even in parallel for different files on the same server.

Another approach might be to create a new file name handler, which just
performs the encryption/decryption job, plus proper handling of file
names. This could be enabled for dedicated remote servers only, and
works in combination with Tramp. That new file name handlers performs the
encryption/deryption locally, and Tramp is responsible for copying
from/to the server.

> The goal here is to be able to save and retrieve files on any server,
> such that the server operator can't determine their contents or their
> names.  Tramp would generate the remote file name to use, encrypt the
> file contents, then write that into the generated remote file name on
> the remote machine.
> Tramp would have to maintain a local table mapping specified (local) names to
> generated (remote) names.
> The data that gets encrypted could contain first the specified file
> name, then a delimiter, then the contents of the file.  That way, if
> you lose the local table or it is lacking some files, but you have the
> encryption key, you can decrypt each saved remote file and find out
> what its original specified file name was.

That sounds unstable. I believe we shall find a way to encrypt/decrypt
the file name with the same passphrase as the contents of the file(s);
by this we wouldn't need to keep a local mapping file. The encrypted
file name could be adapted by base64 then, in order to make it fit to
the file system's naming conventions.

The advantage would be, that we would know the original file name w/o
copying and decrypting the whole file first.

A local mapping table would be in the way, if different people would
like to access a given file from their own Emacs stanzas. That's what
"cloudy servers" are good for.

Best regards, Michael.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]