Re: Tramp and crypted files

[Michael Albinus]

Deus Max <deusmax@gmx.com> writes:

Hi,

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

No. The new tramp-crypt file name handler makes this transparent to
you. Given, you have declared "/nextcloud:host:/crypted/" as crypted
remote directory. If you call for example

(directory-file "/nextcloud:host:/crypted/subdir")

this file name handler will transform "/nextcloud:host:/crypted/subdir"
to "/nextcloud:host:/crypted/XXX", in case you have created a
subdirectory "subdir" and it has the name "XXX" on the nextcloud
server. Then the vanilla Tramp command is called as

(directory-file "/nextcloud:host:/crypted/XXX")

using the encrypted file name. It returns the list ("." ".." "YYY" "ZZZ"),
with "YYY" and "ZZZ" being encrypted file names on the server. This
result is received by the file name handler, and it transforms this list
to ("." ".." "foo" "bar"), with "foo" and "bar" being the plain text
file names of "YYY" and "ZZZ". So, finally you see

(directory-file "/nextcloud:host:/crypted/subdir")
=> ("." ".." "foo" "bar")

without even thinking about that this is a crypted remote
directory. Same scenario for all other magic primitives, which are
implemented by Tramp.

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

No. An encfs mount point is needed only in case you create a new
.encfs6.xml file. Tramp would do this transparently by calling "encfs
tmpdir1 tmpdir2". Then it saves tmpdir1/.encfs6.xml, unmounts the encfs
mountpoint, and removes the temporary directories.

In ordinary use, if a file or file name needs to be encrypted or
decrypted, just the rootdir is necessary, no mountpoint. See this: I
have a root dir at /tmp/rootdir/. There is the crypted file
xyswI5g6Pf3R7qOMKy1jDA8m. And I can still do

--8<---------------cut here---------------start------------->8---
# mount | grep encfs

# ls -al /tmp/rootdir
total 8
drwxrwxr-x.   2 albinus albinus   80 May 29 10:48 .
drwxrwxrwt. 114 root    root    5960 May 29 10:45 ..
-rw-rw-r--.   1 albinus albinus 1297 May 29 10:32 .encfs6.xml
-rw-r--r--.   1 albinus albinus   26 May 29 10:48 xyswI5g6Pf3R7qOMKy1jDA8m

# encfsctl encode /tmp/rootdir foo
EncFS Password:
xyswI5g6Pf3R7qOMKy1jDA8m

# encfsctl decode /tmp/rootdir xyswI5g6Pf3R7qOMKy1jDA8m
EncFS Password:
foo

# encfsctl cat /tmp/rootdir xyswI5g6Pf3R7qOMKy1jDA8m
EncFS Password:
This is file foo.
--8<---------------cut here---------------end--------------->8---

Well, I must confess that I have trouble to make "encfsctl cat --reverse"
working. Will dig what's up.

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

Honestly, I don't care which Tramp method is used. Whether you use a
remote nextcloud server, or a remote ssh server, doesn't matter. The
user must decide what's best.

The same problem you mention happens for all remote files handled by
Tramp, also for not encrypted ones.

For my internal testing, I use as crypted remote directory "/ssh::/tmp/xxx/".
That's fast, and good enough.

> DeusMax

Best regards, Michael.