gocryptfs for Windows - Cross-platform support about gocryptfs

[bailey27]

@rfjakob , @xelra ,

cppcryptfs has reverse mode now.

[Liryna]

Hi everyone,

I am one of the maintainers of Dokany.
I just want to say that if you have any questions about dokany, feel free to ask.
I will do my best to help you !

(I don't have Go knowledge so I cannot do the 'port' my self)

[bailey27]

Hello,

I have implemented the gocryptfs filesystem in a C++ application for Windows using Dokany.

https://github.com/bailey27/cppcryptfs

I'd like to thank rfjakob for making such clear and complete design documents for gocyptfs. It has been a pleasure working from them.

[rfjakob]

I think due to the fact that cppcryptfs exists and is well-maintained we can call this issue fixed 👍

[jkaberg]

IDK if this helps; https://github.com/dokan-dev/dokany

Totally unrelated, just happen to see that project the other day

[pepa65]

Dokany sounds good for many fs deficiencies on Windows!

[rfjakob]

Dokany looks good. It even has a FUSE layer: https://github.com/dokan-dev/dokany/wiki/FUSE

[jkaberg]

Very cool @bailey27, will try this ASAP

PS: You should make some releases

[bailey27]

Thanks for wanting to try it out.

Please let me know if you have any issues building or using it.

I want to wait until cppcryptfs has gained some maturity before doing any binary releases.

[rfjakob]

Wow, awesome work! Congratulations for getting this done!

[bailey27]

Thanks.

I wanted to make the gocryptfs software itself work with Dokany or Dokan Fuse, but I decided it would be too risky for me. I barely know anything about go, and I was worried about having to code and debug in an unfamiliar environment.

Thank you again for making such a well-designed and well-documented filesystem.

[bailey27]

@rfjakob ,

I would like to ask you if you think my "volume label" feature in cppcryptfs is designed correctly (cryptographically).

When cppcryptfs saves the Windows volume label, it converts it from unicode-16 to utf-8 and then encrypts it with the master key using AES256-GCM with a 128-bit random iv and 8 zero bytes of auth data and then base64-encodes it and saves it in gocryptfs conf (in "VolumeName").

Does that sound OK?

[rfjakob]

Yes, that looks fine!

[rfjakob]

@bailey27 I have dropped CBC support in gocryptfs completely with commit 3d59a72 (EME is now mandatory), maybe you want to do the same? Also, GCMIV128 is now mandatory in gocryptfs as well.

[bailey27]

@rfjakob ,

Thanks.

I've dropped support for CBC now. I require GCMIV128 as well.

[rfjakob]

@bailey27 I have added AES-SIV (RFC5297) support in gocryptfs v1.1. AES-SIV does not need unique nonces, and I needed that to implement reverse mode, where I cannot use random nonces.

It's not a default mode and will probably be rarely used for now, but if you want to add it to cppcryptfs, the feature flag is called AESSIV. When it's active, AES-SIV is used instead of AES-GCM for file content. The diagram in https://nuetzlich.net/gocryptfs/img/file-content-encryption.svg applies, with AES-GCM replaced with AES-SIV.

No changes for filenames. As always, an example filesytem for testing is available in the example_filesystem folder.

[bailey27]

@rfjakob ,

Thanks for the heads-up.

I have just now added code for detecting the AESSIV flag and displaying an error message if it is found.

I don't currently have a need for reverse mode. So I don't know if or when I will implement one in cppcryptfs.

But if I do a reverse mode, then I will try to implement AES-SIV.

[xelra]

@bailey27 Reverse mode is great for doing encrypted backups with rsync. Anything that you would have unencrypted locally and only encrypt for storing it remotely. It's a really great feature.

[bailey27]

@xelra ,

I see how reverse mode would be useful.

I am looking at existing C implementations of AES-SIV.

[rfjakob]

Botan ( https://github.com/randombit/botan ) seems to have it. But that's a pretty big library just for AES-SIV.

[bailey27]

@rfjakob ,

Thanks for pointing out Botan.

I think it is too big. If I used it, then I think I might as well stop using openssl and use Botan for everything, which I don't want to do.

I think I'll just lift the AES-SIV code from a project that has a permissive license and put it in cppcryptfs. I think that isn't the ideal way to use code from other projects, but it does reduce the number of dependencies.

I could try to lift it from Botan, but the Botan code seems to depend on the rest of Botan too much.

There's a Ruby extension for aes-siv written in C and on top of openssl, but it's GPL.

There's also aes-siv code in wpa_supplicant, which is BSD.

I also found this one https://github.com/arktronic/aes-siv which has a permissive license.

It seems to work (it passes the test vectors). The project itself doesn't build a library, but instead an executable which is the test program.

I think I'll use the siv and ctr code from it, but use the basic AES primitives from openssl instead of the ones that come with the project.

[bailey27]

AESSIV is working in cppcryptfs. I hope to get started on reverse mode soon.

[rfjakob]

Wow, awesome!

[billziss-gh]

@rfjakob I am finding this issue somewhat late as it looks like you just closed it.

I am the author of WinFsp which is a FUSE solution for Windows and cgofuse which is a cross-platform FUSE library for Go, with OSX, Linux and Windows support. WinFsp and cgofuse have already been used to port rclone mount to Windows.

If you are still interested in a Windows port I would be glad to help.

Caveats:

• Cgofuse has its own API which is incompatible with hanwen/go-fuse that gocryptfs currently uses.

  • Cgofuse only provides a high-level (path based) API rather than a low-level ((parent_ino, name) based) API.

• Cgofuse uses cgo to interface with the native implementation of OSXFUSE (OSX), LIBFUSE (Linux) and WinFsp (Windows). Unfortunately cgo can make builds complicated, because it requires native tools even when cgofuse is distributed as a prebuilt binary.

  • Projects that use cgofuse can optionally use xgo and the docker image billziss/xgo-cgofuse to make cross compilation easier. [more]

I understand that these are some hard caveats and you are probably unwilling to choose such a route. However if you decide to go ahead you can count on my support.

[Liryna]

Congratulation again to @bailey27 for porting cryptfs to windows and maintaining cppcryptfs perfectly !
A great work has been made here ! 🏆 🎉 🎖️

[rfjakob]

@billziss-gh I have noticed WinFsp when you have mentioned it over at cppcryptfs. I love the emphasis you put on testing and the work you have done there. The project looks excellent.

For gocryptfs, I don't think I'll want to swap out the FUSE library. go-fuse is very stable now, but the distinct advantage is that it is all-Go, which means gocryptfs can compile (./build-without-openssl.bash) to a static binary without dependencies. I think is a big usability gain for Linux users and from gocryptfs v1.4 onward I'll release only the static build.

[billziss-gh]

@rfjakob thank you for the kind words re: WinFsp. I agree on the importance of testing and note that gocryptfs is already very well tested. Great work.

For gocryptfs, I don't think I'll want to swap out the FUSE library... but the distinct advantage is that it is all-Go

I actually agree. Cgofuse introduces some hard requirements and dependencies, which I am not happy about. I would love to find a better way to get cross-platform FUSE support on Go without the cgo requirement.