Gocryptfs: Document manual decryption (if possible)

[rprieto]

For me, a strong point in favour of gocryptfs over other alternatives (e.g. securefs or CryFS) is that it seems I'll always be able to decrypt my files without much effort. No complex data structures to traverse or chunks to join manually.

For example if I find an old archive (and its master key) 10 years from now, even if I run on a new fancy operating system that gocryptfs doesn't support, I could probably write a shell script that renames all files and decrypts them using openssl... just like I could do if I manually used tar and gpg.

Is that accurate? If so it would be awesome to have some something in the website/docs that emphasize the no vendor lock-in aspect and show a basic example of decrypting a folder.

[rfjakob]

I think the file file-format and the used crypto is quite well documented and should enable you to write a decoder quickly. That's also what @bailey27 , who created cppcryptfs, said.

I have started something like a standalone decoder, gocryptfs-xray (does not decrypt the data yet)

However, I'm not sure if can do it just from the command line. The first roadblock is that according to the
openssl manpage, AES-GCM is not supported by the command line utility.

[rprieto]

You're right, and thanks for putting all these docs together!

Good point about openssl. I had run the following, but apparently this only means it supports GCM when used as a library, not from the command line.

 $ openssl enc -help 2>&1 | grep gcm 
-aes-128-gcm -aes-192-gcm -aes-256-gcm

Extra binary "helpers" like gocrypt-xray sounds really good 👍

Would you consider making it a separate project/repo? I'm asking because I've had trouble building gocryptfs on OSX, but since the standalone tools will be very small and don't need FUSE support they should be very easy to build cross-platform. In a way it'd be like having gocryptfs as the stable filesystem specification, and satellite repos for different tools (Windows version, decryption utilities... mobile app?).

I'm happy to close this issue.

[rfjakob]

I think separating the xray tool would make it harder to keep it in sync with gocryptfs.
Actually I thought gocryptfs would build fine (and even work more or less) or OSX. But you can build gocryptfs-xray without having the go-fuse libraries installed, it does not depend on any.

[rprieto]

That's a good point. Do you think there will be many changes to the structure and spec now that you've reached 1.0? Otherwise having a formal/canonical spec would be really nice to encourage other tools to be created (if that's something you're interested in).

I'll give building on OSX another try, and also looking forward to releases having Macos binaries!

[rfjakob]

I guess the problem on osx, if any, is getting the right version of openssl installed. The use of openssl is optional and only a performance optimization, but currently you always need it for compilation.

I'll add a way to build gocryptfs completely without openssl next week (using Go build tags).

[rfjakob]

The file and directory structure is stable and I don't expect changes. However, v1.1 will add another encryption algorithm for file contents, AES-SIV. Which algorithm is used is indicated in the config file.

[rprieto]

Thanks. Depending on what I try on macOS, I get a mix of

gocryptfs/internal/stupidgcm/locking.go:9:10: fatal error: 'openssl/evp.h' file not found
#include <openssl/evp.h>

Looks like a wrong version of openssl, I'll figure out how to pass the right library paths - or the option you mentioned without openssl sounds great :+1:

and

package .
        imports github.com/rfjakob/gocryptfs/internal/configfile: use of internal package not allowed
package .
        imports github.com/rfjakob/gocryptfs/internal/contentenc: use of internal package not allowed
package .
        imports github.com/rfjakob/gocryptfs/internal/cryptocore: use of internal package not allowed

(which is an odd one...)

But this is all unrelated to this issue, so I'll close it. Looking forward to gocrypt-xray!

[rfjakob]

You can now build without openssl using ./build-without-openssl.bash

The use of internal package not allowed looks like gocryptfs is not in the directory the Go compiler expects it to be?

[rprieto]

Thanks that's brilliant!

_(sorry about use of internal package not allowed, that's a weird issue that pops up every few builds but looks related to my setup. Nothing to do with gocryptfs)_