EncFS development ?

[benrubson]

Hi,

Of course I think I'm not the only one to widely use encfs, which is a very nice and useful product.
I then think that many of us would really be happy to see the encfs development start again, at least to correct the well known security issues.

@vgough, may I then ask you, do you have some plans regarding this ?
@rfjakob, perhaps you also have some plans ?

Here is the list of important security issues :

• Same Key Used for Encryption and Authentication : Same Key Used for Encryption and Authentication #8
• Stream Cipher Used to Encrypt Last File Block : Stream Cipher Used to Encrypt Last File Block #9
• Generating Block IV by XORing Block Number : Generating Block IV by XORing Block Number #10
• File Holes are Not Authenticated : File Holes are Not Authenticated #11
• 64-bit MACs : 64-bit MACs #13
• 64-bit Initialization Vectors : 64-bit Initialization Vectors #16
• Information Leakage Between Decryption and MAC Check : Information Leakage Between Decryption and MAC Check #17

Related improvement ?

• Switch to libgcrypt : switch to libgcrypt #19

Interesting improvements :

• Implement per-directory configuration : implement per-directory configuration #5
• Alternative filename storage for very long filenames : alternative filename storage for very long filenames #7

I pushed some PR in the past few weeks to correct some issues, to improve error checking, to add some new options... but not sure I'll be able to handle the above few points.

Many thanks for your feedback 👍

Ben

[samrocketman]

I'm adding a comment because I'm interested in this discussion. I mostly just do code reviews for this project and find little things here and there to contribute.

[danim7]

Hello, I completely agree with you, encfs is a very useful tool, and it would be great if the security issues from the audit were resolved. I have the impression that most of them could be resolved in "one shot" just by moving to the GCM cipher mode of operation with 128 bits IVs and MACs. Libgcrypt supports this mode of operation,and surely openssl, and I proposed a PR following the open issue. Even more, I don't think it would be very difficult to move to GCM if you don't mind having a "whole new" version 2.0 that doesn't read the current disk format, forcing users to a manual migration to the new version... Is there any roadmap or active development in order to fix those issues? Best regards !

[rfjakob]

The EncFS project has been running for pretty long now, the git history goes back to 2008, and the first release was 2003. Development has stalled for a while until the project moved to Github in 2014 with the help of @samrocketman . The original author, vgough, put this paragraph on the front page:

EncFS has been dormant for a while. I've started cleaning up in order to try and provide a better base for a version 2, but whether EncFS flowers again depends upon community interest. In order to make it easier for anyone to contribute, it is moving a new home on Github. So if you're interested in EncFS, please dive in!

There are still fixes and smaller changes being merged, and occasionally vgough pushes a bigger thing (like replacing the whole build system with cmake). This is mostly maintainance, though. There is no development happening towards a new on-disk format that fixes the security issues, the so-called "EncFS 2.0".

I think to make EncFS 2.0 happen we will need somebody to step up and lead the "2.0 project".

[ostaszewskik]

Why I don't see 2.x branch? I hear about Encfs 2.0 coming, but I cannot find the code... @vgough if you provided a crowdfounding page to support the project, I'd happily make a PayPal donation.

[rfjakob]

Well, that's because it does not exist. As you may know, my opinion for EncFS 2.0 was to start afresh, and the result is called gocryptfs. It's stable already and has been audited recently.

[benrubson]

Thank you very much @rfjakob for your feedback 👍

Do you have some news from @vgough ? Do you think he would be OK to lead the 2.0 project ?
Perhaps some issues could be simply corrected without having to change the whole on-disk format, simply changing encfs behaviour depending on the configuration file version.

Perhaps we could also think about closing issues which do not need to be opened anymore ?
We would have a better view.

And what about PR which are opened, will they be reviewed & merged ?
BTW, IMO, we may pay attention to code sanity (functions return code, error handling...) which is really important in a data encryption product.

Many thx again 👍

[samrocketman]

vgough (the original author) moved it to Github in 2014

One minor correction, though not very relevant for the overall discussion. I migrated the project from SVN preserving authorship. That's how I have commit access despite not making any meaningful contributions (other than the migration, some documentation, and a few reviews).

I'm mostly a user of EncFS and cared about it continuing.

[rfjakob]

Ah, I was not aware of that, nice! I updated my comment.

[rfjakob]

@benrubson No, I have not heard from vgough for a while, but he does merge pull requests every now and then. I'll also continue to try to review and merge pull requests. But I can only merge things that I can confidently judge as safe.

As for the 2.0 project, I think somebody else will have to lead it.

[benrubson]

Thank you for your feedback @rfjakob and for your effort trying to review pending issues & pull requests 👍
Let's hope we will have some news from @vgough :)

[ostaszewskik]

@rfjakob many thanks for providing info about your project gocryptfs! Can you post a link to a security audit? As far as I know among gocryptfs, ecryptfs,cryptomator, securefs, CryFS and encfs only the last one has had a professional audit. For that reason I prefer to keep on using a software with known holes rather than believe others don't have it.

[rfjakob]

The gocryptfs audit is here: https://defuse.ca/audits/gocryptfs.htm
If you have any questions or comments, feel free to post in the "Audit Results" ticket: rfjakob/gocryptfs#90

[emanuil-tolev]

@rfjakob I appreciate gocryptfs (I use it), but there are a lot of usability issues around it. EncFS is currently usable on Android, gocryptfs is not. I just went through 2 hours of compiling SiriKali and gocryptfs on a friend's Mac, with the end result of gocryptfs being unable to mount the volume (could be a go-fuse issue rather than crypto issue). We have both EncFS and gocryptfs volumes, so we could compare .. and EncFS just worked immediately on the Mac.

Starting afresh is probably the best option 14 years later, but there's a lot to still do.

[benrubson]

EncFS is currently usable on Android

I agree, as I stated there :
I also think that it would be nice to keep encfs maintained : it has been audited, so security issues are known, and then could certainly be corrected.
In addition it is widely used, sometimes in production environments, it's then quite difficult to migrate from encfs to another product.
It is also written in C++ which makes it easy to install on a wide range of systems : Linux, FreeBSD, Synology / Qnap...
Perhaps we could start the dev again ? Would be really nice 👍

[samrocketman]

One comment I'd like to add. As a user of EncFS I really appreciate all of the work @vgough @rfjakob @benrubson @danim7 @charles-dyfis-net @jetwhiz and all of the contributors who have kept this project alive. I enjoy using your work to secure personal files.

[benrubson]

Let's hope we will have some news from @vgough :)

We do have, many thanks for being back into the business since a few weeks 👍

[vgough]

Thank you all for keeping encfs alive. A few years ago, I had created a development branch to really cleanup code, separate out legacy cipher from new cipher framework, and add a few alternatives to openssl. Some bits of that, like cmake support, were eventually merged into master, but I don't have that kind of time today for large changes.

If I were to start over, I like rfjakob's work on gocryptfs, in part because Go has been my primary language for work the last 3 years. If you're running on Linux, I'd give it a try. Unfortunately the "pure go" FUSE library may be hit or miss for a while, since what's really standardized in FUSE between platforms is the FUSE C API rather than the wire protocol.

Eventually I expect that the available Go FUSE libraries will be good enough to work on all platforms, and if I were to start encfs today I would almost certainly use a language like Go.

[benrubson]

Unfortunately yes the go FUSE lib is not available everywhere, whereas the FUSE C API is, and is really actively maintained and updated.
This makes the C++ EncFS project compatible with almost everything, Linux, Mac, *BSD, every unix box... Even Windows... This is why I like it 👍 Whatever the devices we are going to use, we will be able to rely on EncFS, as we always did. This makes EncFS a strong competitor 👍

I think that with last committed bug corrections, sanity checks and lint methods, the upcoming version will be nice and "strong".

Improving it at least correcting security issues listed in first post would make it brillant, without having to migrate (personal usage and/or productions) to a new product (which is then sometimes impossible).
For sure we are not so far from this !

Many thanks 👍

[ghost]

@vgough Hey, I've been using your software for some years and I love it, thank you for creating it. I reccomend it to my friends if they're interested in securing data. Also a thanks to @rfjakob @benrubson @danim7 @charles-dyfis-net @jetwhiz and all other contributors who helped make this software great.

[mouse07410]

@benrubson a late-comer with an improvement suggestion: add the ability to use smart card (say, PIV and OpenPGP) for volume key wrapping (asymmetric crypto).

[samrocketman]

Thanks for your work @benrubson

[buhtz]

Hello,
I'm member of maintenance team of Back In Time depending on EncFS. We are aware of the security problems and finguring out how to deal (bit-team/backintime#1549 and bit-team/backintime#1248) with it without breaking to much of our features.

I would strongly suggest to update your README.md about the current project status including a time stamp. From reading your README.md it is not clear what is going on. Also the repo itself is not archived yet.

To my understanding EncFS is not in active development and won't be in the future.
The suggest from EncFS maintainer is to move to gocrytfs. Am I right so far?

Does anyone have a migration guide?

[samrocketman]

It's kind of in the same state as it was originally. It's up to project contributors to drive the project; so if nobody is contributing it stagnates. That doesn't necessarily require the repository to be archived.

If by current maintainer suggesting gocryptfs you mean, vgough; I don't see how they suggested what you should use instead. They were musing on if they had to do it all over they'd start with Go and come up with something like gocryptfs. Their comment was clear at the time that go-FUSE didn't provide as good of portability as C bindings. Bear in mind this comment was written 6 years ago so a lot could have changed.

I don't think quoting such an old comment and holding it as their current opinion presents their intent in good faith.

I doubt anyone here can help with your migration unfortunately (I just use EncFS and others took up the mantle to contribute to EncFS but then moved on to other things). Such is the way of open source sometimes.

In general, file based encryption at the file level is going to have some limitations; I suggest looking more into encrypting TAR via standard, modern encryption, such as GPG. In my case, I encrypt my drives with LUKS. I would look at solutions which provide fully wrapped encryption if you want to avoid the security issues pointed out completely (i.e. having multiple copies of encrypted files whose known contents is changing could weaken their seal).

[charles-dyfis-net]

@samrocketman, ...to admittedly go off on a tangent from a very minor piece of your comment (which I otherwise have no qualms with) -- I'm not sure GPG can be described as modern (though OpenPGP being literally standardized, there's no room to argue with "standard").

We know better today than to try to build indefinitely backwards-compatible protocols (enabling downgrade attacks and the ability for attackers to construct content that triggers little-used or untested codepaths, both of which OpenPGP implementations are prone to), which is why modern tools like minisign or saltpack or age deliberately bake in their algorithm choices.

We know better today than to try to build encryption tools with streaming APIs that treat decryption and signature validation as two completely separate operations (such that content can be decrypted and streamed to stdout -- and thus used by software trying to consume it -- before any signature validation is performed; older versions of OpenPGP also let an attacker strip the signature packets altogether without causing a consumer to even exit with a nonzero status -- but when you're streaming a decryption operation to something like sh or tar that immediately enacts its input, a nonzero exit status comes too late anyhow, making piping stdout from even modern OpenPGP risky).

We know about Authenticated Encryption with Associated Data -- with widespread and solid implementations of algorithms like GCM sitting at the heart of newer tools -- and the importance of designing wire protocols and data formats to make the obvious and easy implementation more likely to be correct, design considerations that were a decade away from being taken seriously in cryptography when PGP was first designed.

Today, we know better than to use PGP.

[samrocketman]

Today, we know better than to use PGP.

Didn't mean to paint myself as an expert; hopefully I made clear I am a user of EncFS and don't really dive into its internals.

The only reason why I'm particular to using GPG over other tools is during the snowden revelations the leaked NSA files mentioned GPG gave them trouble. So as an encryption layman I tend to lend it some trust from that real world breach of information. I don't have any scientific reasoning as to why anyone should use anything so I probably shouldn't have suggested any alternatives; I was trying to be helpful but it could lead others down the wrong path in this case.