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.
That 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).
Some 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.
Every consultancy/consultant/project is different, but it's unlikely that they sat down with the code at 10AM and sent the report out at 8PM. It's not uncommon for there to be some unbilled hours, for instance if the consultant ends up researching a new technique/vulnerability and they will be able to re-use the knowledge in other projects. So don't feel bad :)
Leaking 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.
Issue 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.
Is 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.
Indeed, 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.
Does 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).
I use Truerypt and Dropbox. They play well together.
ps. I have repeatedly encountered people who falsely assume that Truecrypt does not allow incremental backups with Dropbox. The thinking behind this seems to be assumption cipher-block chaining (CBC) is used. Truecrypt uses XTS mode.
Does Truecrypt sync changes when a file inside the container is changed, or when the container its self is unmounted? I seem to recall having issues with this a few years ago when I tried it out. Probably something to do with Truecrypt maintaining a filesystem lock or something?
Needless to say, with encfs on Dropbox, files are synced as soon as they are changed.
Thought so. Truecrypt is no use for me then. I need something that will sync changes as they happen, or at least shortly afterwards. I don't want to have to unmount and remount my Truecrypt container once an hour or whatever to sync changes.
Assuming the size of the files isn't that big, you could always keep an unencrypted copy that you actually work on, and then periodically a script would mount the container, rsync the unencrypted directory to it, and unmount it so it can be synced.
Sure the unencrypted copy would be exposed, but not to any process that couldn't already access the mounted directory, as far as I can see.
1. Keep TC container in a non-shared location on local disk
2. Mount it, keep it mounted
3. Periodically backup this location to your Dropbox folder
Now, the trick is to use backup software that is capable of
(a) shadow copying
(b) incremental file updates
Shadow copying works around .tc file being locked.
Incremental updating keeps things quick.
The only Windows software I know that is capable of this is Bvckup 2 - http://bvckup2.com
(I posted this earlier, but then deleted the post as it read kind of spammy. But this is the way to handle TC container backup, so here it is again. And that's one gem of a backup program too, totally worth a plug).
Then you end up with duplicate local copies of your entire container. Seems very wasteful to me... Especially as TrueCrypt forces you to pre-allocate all the space that you think you'll need.
I don't know whose thinking that is, but when I recommend against Truecrypt on Dropbox, it's because you can't auto-merge two diverging Truecrypt volumes even if the two changesets are unrelated.
This is a frustrating table; it's got irrelevant details (like which of a variety of ciphers are supported) but nothing on what constructions and modes are used, which KDFs are supported, how nonces are handled, &c.
It would be one thing if all these systems used roughly the same XTS construction, like modern full disk encryption systems. But they don't; they use '90s constructions like block-addressed CBC.
Yea, that's what I researched to initially get the idea to use EncFS. I forget why I discounted ecryptfs, it may be because that page doesn't make it look great for cross-platform support.
That's also what I mean. If I have to think about the encryption during day-to-day operation, the encryption has failed. That's why I <3 full disk encryption: it seamlessly works.
Yeah, I too, though it does not help with things like Dropbox. You need to add a second encryption inside your full disk encryption separately for everything that has direct access to the files. And that is exactly where encfs shines (even though I also use it for home, but that is a different story).
I 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.
You 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 ;)
Contradictory 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.
What 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?
How? EncFS is mainly used, at least by me, to store the encrypted files in Dropbox/X while working on the decrypted ones in parallel. Does LUKS support that? The Arch table linked above doesn't make it sound like that.
In just 10 hours? If really so color me impressed. I don't think I've been so productive in 10 hours, ever.