Feature Request: Reverse Mode

[usr42]

Add an option similar to the --reverse option for encfs:

Normally EncFS provides a plaintext view of data on demand. Normally it stores enciphered data and displays plaintext data. With --reverse it takes as source plaintext data and produces enciphered data on-demand. This can be useful for creating remote encrypted backups, where you do not wish to keep the local files unencrypted.

For example, the following would create an encrypted view in /tmp/crypt-view.

encfs --reverse /home/me /tmp/crypt-view
You could then copy the /tmp/crypt-view directory in order to have a copy of the encrypted data. You must also keep a copy of the file /home/me/.encfs5 which contains the filesystem information. Together, the two can be used to reproduce the unencrypted data:
ENCFS5_CONFIG=/home/me/.encfs5 encfs /tmp/crypt-view /tmp/plain-view
Now /tmp/plain-view contains the same data as /home/me
Note that --reverse mode only works with limited configuration options, so many settings may be disabled when used.

(Quote from encfs man page)

[rfjakob]

Reverse mode really is a nice feature. However, with reverse mode, there is no permanent store for the ciphertext (everything is encrypted on the fly and not stored). That means that gocryptfs could not store the file and block headers permanently.
encfs disables both in reverse mode, but this comes at a security cost, and is impossible for gocryptfs because GCM encryption absolutely needs a block header.
Now gocryptfs could just generate new block headers for every access (they are random anyway). But this would mean that you get different ciphertext every time you read a file (it still decrypts to the same plain-text, of course). This would make it pretty painful for backup purposes.

In short, I don't see a way to do this in a useful way for gocryptfs.

[rfjakob]

GCM-SIV ( https://tools.ietf.org/html/draft-irtf-cfrg-gcmsiv-01 ) looks like a way this could be implemented. Reopening.

[fulldecent]

Added $100 bounty:

https://www.bountysource.com/issues/31871717-feature-request-reverse-mode

[rfjakob]

@fulldecent Question: Do you need a writeable reverse mount or is read-only good enough?

[fulldecent]

I am happy with read only. My use case is secure backups with rsync.

If somebody needs read-write, maybe that can be a separate issue.

[bgw]

Added another $20 to the bounty.

[rfjakob]

Just FYI: I have started working on this in the "reverse" branch. I'll travel abroad for two weeks now but I expect to have things in a testable state by the end of September.

[fulldecent]

Very cool, thanks for the update

[rfjakob]

This is essentially done. Fetch the latest "reverse" branch if you want to test it.

However, it uses the GCM-SIV Go reference implementation from github.com/agl/gcmsiv which is painfully slow at about 2 MB/s.

I am thinking about switching to AES-SIV, which has a reasonably fast Go implementation and the format is finalized (RFC 5297). Votes against?

[bgw]

This is essentially done. Fetch the latest "reverse" branch if you want to test it.

Awesome! I'm skimming through the code. When trying to run go get in the branch, I'm getting:

package github.com/rfjakob/gocryptfs/internal/fusefrontend_reverse: cannot find package "github.com/rfjakob/gocryptfs/internal/fusefrontend_reverse" in any of:
        /usr/lib/go-1.6/src/github.com/rfjakob/gocryptfs/internal/fusefrontend_reverse (from $GOROOT)
        /home/bgw/.golang/src/github.com/rfjakob/gocryptfs/internal/fusefrontend_reverse (from $GOPATH)

However, I don't know if this is because I'm doing something wrong. I'm not a Go developer.

I am thinking about switching to AES-SIV, which has a reasonably fast Go implementation and the format is finalized (RFC 5297). Votes against?

The code looks better maintained too, so it seems like a good decision. However, I don't know enough about the pros/cons of these different cryptographic methods to intelligently comment.