Why does BIT use EncFS?

[ovalseven8]

First of all thank you to all developers who created this useful software!

I absolutely appreciate it that you can make encrypted backups! 👍
However, I wonder why EncFS is used for it? It's known that there are some security flaws in EncFS that are not fixed for a long time now -> vgough/encfs#9.

Would be cool if BIT could use better maintained and more secure encryption technologies!

[Germar]

The main reason for EncFS is the --reverse feature. I don't know of any other Fuse encryption which support a reverse mode where you can mount plain files to view their encrypted part in the mountpoint. This is very helpful for rsync as you can simply sync the encrypted files to a remote server.

[rfjakob]

gocryptfs can do this since v1.1, released a week ago. Note: I am the author. And a happy BackInTime user, by the way.

[Germar]

Awesome! Will have a look, soon. It's not yet in official distribution repositories, is it?

[rfjakob]

No. Debian packaging is in progress: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839279

[Germar]

Okay, I played a bit with gocryptfs and already love it!

@rfjakob just to get it right: if I sync the encrypted view (mounted with -reverse) into an already existed cipher folder which is using the same gocryptfs.conf, can I view its plain view again? Okay, hard to understand, here is an example:

$ mkdir 0_plain_source 1_reverse_cipher 2_snapshots_cipher 3_plain_snapshots
$ gocryptfs -init -reverse 0_plain_source
$ gocryptfs -reverse 0_plain_source 1_reverse_cipher

# copy .conf and .diriv and mount a plain version again
$ cp 1_reverse_cipher/gocryptfs.* 2_snapshots_cipher/
$ gocryptfs 2_snapshots_cipher 3_plain_snapshots

# create first snapshot
$ touch 0_plain_source/foo
$ touch 0_plain_source/bar
$ mkdir 3_plain_snapshots/1               #cipher is wjaw0muxj3k3S394reHfiQ==
$ rsync -avi 1_reverse_cipher/ 2_snapshots_cipher/wjaw0muxj3k3S394reHfiQ\=\=/

# create second snapshot
$ touch 0_plain_source/baz
$ mkdir 3_plain_snapshots/2               #cipher is Gc5Ti-2_o2hsZ0hSgFLjqQ==
$ rsync -avi 1_reverse_cipher/ 2_snapshots_cipher/Gc5Ti-2_o2hsZ0hSgFLjqQ\=\=/ --link-dest=../wjaw0muxj3k3S394reHfiQ\=\=/

$ tree -a ./
./
├── 0_plain_source
│   ├── bar
│   ├── baz
│   ├── foo
│   └── .gocryptfs.reverse.conf
├── 1_reverse_cipher
│   ├── 6TpGJIphzTgQGHmIFzq6Ag==
│   ├── fxO9R9y-asl7ZIsA6QBBeA==
│   ├── gocryptfs.conf
│   ├── gocryptfs.diriv
│   └── uYddAquGdv7Hs3718Da1Yg==
├── 2_snapshots_cipher
│   ├── Gc5Ti-2_o2hsZ0hSgFLjqQ==
│   │   ├── 6TpGJIphzTgQGHmIFzq6Ag==
│   │   ├── fxO9R9y-asl7ZIsA6QBBeA==
│   │   ├── gocryptfs.conf
│   │   ├── gocryptfs.diriv
│   │   └── uYddAquGdv7Hs3718Da1Yg==
│   ├── gocryptfs.conf
│   ├── gocryptfs.diriv
│   └── wjaw0muxj3k3S394reHfiQ==
│       ├── fxO9R9y-asl7ZIsA6QBBeA==
│       ├── gocryptfs.conf
│       ├── gocryptfs.diriv
│       └── uYddAquGdv7Hs3718Da1Yg==
└── 3_plain_snapshots
    ├── 1
    │   ├── bar
    │   └── foo
    └── 2
        ├── bar
        ├── baz
        └── foo

Is there a way to de-/encode filenames like it is done with encfsctl decode?

[rfjakob]

Yes, this should work. Keep an eye on syslog, where gocryptfs will log warnings. For example, having gocryptfs.conf in the subfolders will cause this:

gocryptfs[4169]: Skipping entry "gocryptfs.conf" in dir "./VSFgWXZzhrqdbK9a6lxdPA==": illegal base64 data at input byte 9

I suggest to skip gocryptfs.conf when copying to the subfolder. Otherwise this will cause a Directory not empty error when you try to delete the folder.

No, there is nothing like encfsctl decode yet. You need to know the encrypted names of the directories "1" and "2", right? You could find it using the inode number, which is identical in encrypted and plaintext view. Example:

$ mkdir 1
$ ls -li                                                  # alternatively: stat -c %i 1
63202 drwxrwxr-x. 2 jakob jakob 60 31. Okt 09:12 1
$ cd ../2_snapshots_cipher
$ find . -inum 63202
./VSFgWXZzhrqdbK9a6lxdPA==

Note that this does NOT work in reverse mode because reverse mode uses arbitrary inode numbers.

[Germar]

Yeah, I guess it would be best to store both gocryptfs.conf and gocryptfs.reverse.conf offside in the snapshot folder and use gocryptfs -config /path/to/gocryptfs.conf instead.

find -inum won't work because I need to de-/encode lot's of file names. For example all ex-/includes. Also while building the permissions file I need to decode each and every filename.

Best would be an API so I could access it directly in python 😉. Hmm, looks like I need to learn some Go...

[rfjakob]

How do you handle that currently with encfs? Call encfsctl for every filename?

What would probably be the sanest way to do this is adding a control interface to gocryptfs. Maybe a socket in /var/run that you can open and pass JSON encode/decode requests. What do you think?

[Germar]

Nope. That would take to much time. I start an encfsctl decode instance which will listen for cipher file-names on stdin and print plain file-names to stdout or vice versa with encfsctl encode.

A socket would be great! Maybe in /var/run/USER/gocryptfs/PID

[rfjakob]

It's probably best to let the caller choose the socket location, in other words, have a cli option "-ctlsock" that takes a path. If the option is not passed no socket is created.

[rfjakob]

Ok I have added the control socket functionality. The option is called -ctlsock.

The JSON interface is very simple, you pass something like

{"DecryptPath":"4RQq1dJlfvQPaVU5Xypf0w=="}

and you get

{"Result":"file","ErrNo":0,"ErrText":""}

Or, for encryption:

{"EncryptPath":"dir"}

Response:

{"Result":"v6puXntoQOk7Mhl8zJ4Idg==","ErrNo":0,"ErrText":""}

ErrNo is a Linux error code, 0 for sucess. It is -1 if there was an error but the error code is not available. The ErrText should explain what went wrong in any case.

Edit: reverse mode has both encryption and decryption implemented, forward mode only has encryption for now.

[edit: forward mode has ENcryption, not DEcryption]

[Germar]

Wow. That was stunning fast! Thanks a lot! I wish I could do my part in the same pace 😩

[rfjakob]

Don't worry, take your time :)

[mossroy]

Another library that seems to do a similar job is https://github.com/cryptomator/cryptolib
It's written in Java, and has also been ported in Objective-C : https://github.com/cryptomator/cryptomator-objc-cryptor
I did not look into details about the "reverse" mode, though.

[Germar]

@mossroy are you sure about reverse in Cryptomator? I can't find any info about it!? But anyways, I'm working on gocryptfs support...

[mossroy]

No, I meant that I did not look into the technical details of this library at all.
It's possible that this reverse mode is not implemented, I don't know.

[gslndlb]

If you want to use more secure encryption technologies, you can encrypt your hard drive, using Luks for example. tutorial for Luks

[emtiu]

Closing this as outdated, the discussion continues in #1248.