15 ms·
EncFS Security Audit
- albinoloverats 13y agoNice to see this kind of report, even if the conclusion is rather damning. And it seems to suggest that using it with (something like) Dropbox is a bad idea too: > EncFS is not safe if the adversary has the opportunity to see two or more snapshots of the ciphertext at different times.
- mysteriousllama 13y agoBoxcrypter uses EncFS. Combined with the vulnerabilities discussed in this audit, this is pretty bad.
- icebraining 13y agoBoxcrypter uses EncFS. Not anymore: https://forums.boxcryptor.com/topic/opening-linux-encfs-encrypted-folder-with-boxcryptor-what-are-the-settings-for-bcencfs-to-do-so#post-5164 https://forums.boxcryptor.com/topic/opening-linux-encfs-encr...
- nieve 13y agoIs the current, non-EncFS compatible version open source for the crypto components or audited by anyone reputable? If not we don't necessarily have any reason to believe it's safer.
- tjaerv 13y agoIndeed, a priori one would have to assume it less secure than an open-source implementation that has been reviewed by experts. "We built our own" merely amounts to security through obscurity.
- mmmooo 13y ago> This report is the result of a paid 10-hour security audit In just 10 hours? If really so color me impressed. I don't think I've been so productive in 10 hours, ever.
- perlgeek 13y agoFWIW it looks to me like this mostly isn't a code review, more of a conceptual review of how stuff is done and stored. I can imagine that's way faster than doing a thorough code review, though the number of results from 10 hours is still very impressive.
- tptacek 13y agoThat seems to be the case, but I couldn't find any rigorous documentation on the crypto EncFS uses, so I imagine even this level of review required code review (that's also the only way you get a finding like the timing-leaking MAC validator, though I dispute that finding's "Medium" severity and think it's sev:lo).
- mmmooo 13y agoSome of it must have required at least some level of code review (e.g. (MACFileIO.cpp, Line 209)). Even so, between the review, and the writeup, etc, if the total 'billed hours' is really ~10, the rather large hourly rates I've seen for such audits do appear much more appetising, at least to me.
- tjaerv 13y agoFor the particular reviewer who did this work, anyhow.
- earthrise 13y agoHere's the rough process I followed when I did that audit: https://defuse.ca/b/hwwW9d3FkPGhM4T6xBIbhf https://defuse.ca/b/hwwW9d3FkPGhM4T6xBIbhf I think the reason I found so much in only 10 hours is that I had a good set of guesses about what could be wrong, based on what I've seen people get wrong before. From there it was just a matter of prioritizing which guesses to check. I did look at a lot of the code, although it was mostly guess-checking combined with a closer look at the cryptography code. Because the audit was so short, the quality of the report suffered (ASCII, some mistakes, some severity ratings that I no longer agree with, etc.). My priority was to find as many problems as possible in the amount of time I was given, and then sort that out later. To answer some other replies: I always report unbilled hours (in this case none), since I think it's dishonest to say you worked less hours than you did. You would essentially be claiming to be more productive than you really are.
- akerl_ 13y agoDoes anybody have suggestions for an alternate tool? Preferably one that also encrypts at the file level so that it plays nice with Dropbox and similar services (while obviously providing more security).
- zokier 13y agoJust use full-disk encryption, eg. dm-crypt.
- icebraining 13y agoHow does that play nice with Dropbox and similar services?
- akerl_ 13y agoI do use full-disk encryption for my local disk as a whole, but for things inside syncing services like Dropbox, block-level encryption kills a number of the useful features and ends up wasting way more transfer to sync changes. I know they could potentially do cute de-duping tricks on their end, similar to tarsnap, but even if they passed those space savings on to me I'd still lose the file-level features. That's why I chose EncFS to begin with, and asked for potential other file-level tools to replace it. Realistically, I'd prefer if this expedited EncFS 2.0 and 2.0 fixed the noted issues.
- peterwwillis 13y agoYou could use a revision control filesystem like Git on top of the block encryption of dm-crypt [in a loopback]. Git takes care of de-duplication and compression for you, so the blocks you transfer are just changed ones. Of course, this also means your Dropbox will never shrink, so I hope you really like keeping old copies of files ;)
- phaer 13y agoGnuPG can encrypt files and is more secure.
- SEJeff 13y agoMoral of the story... Use LUKS.
- fluidcruft 13y agoFollowup eCryptFS audit: https://defuse.ca/audits/ecryptfs.htm https://defuse.ca/audits/ecryptfs.htm
- fulafel 13y agoContradictory docs, ECB in filename encryption, sounds like nobody has even looked at this before... though maybe it doesn't have that many safe applications even from conceptual PoV, since all metadata is leaked.
- ghubbard 13y agoWhat is the current state of EncFS development? The last official release seems to have been in November 2010. Are any of the issues raised by this audit being addressed?
- mrpdaemon 13y agoLeaking the file size (Issue 2.2) is due to the way EncFS is architected to work at a file granularity. Adding some random bytes or rounding up to the next block size are small improvements but still leak approximate file size. I don't think anyone would like their 5KB file to occupy 2GB on disk so EncFS sacrifices some level of privacy for practicality. On the flip side this design tradeoff allows EncFS to be used somewhat effectively on top of cloud storage services like Dropbox/GoogleDrive etc. whereas full disk encryption schemes don't work as well.
- klodolph 13y agoIssue 2.2 has nothing to do with leaking the file size. It has to do with the encryption algorithm used. Most modern encryption schemes operate on blocks of a certain fixed size, but if the file isn't a multiple of the block size, you have to do something special with the last block. EncFS apparently uses some made-up scheme for this, instead of using something more standard and well-understood. The common choices would be padding and ciphertext stealing. http://en.wikipedia.org/wiki/Ciphertext_stealing http://en.wikipedia.org/wiki/Ciphertext_stealing