Security questions about EncFS implementation

meinusername

Hey there,
I just bought the pro version and I'm wondering about the security of the implementation since I just read this:
https://boxcryptorsupport.uservoice.com/knowledgebase/articles/35105-can-boxcryptor-mount-encrypted-volumes-created-wit

"No filename initialization vector chaining
No per-file initialization vectors
No external IV chaining
No block MAC headers
No per-block random bytes"

?
Please tell me about those missing 'features'!

Robert

Hi!

BoxCryptor already offers a great level of security by using AES-256 encryption which has been approved for top-secret information. Although this level of security is already very high without these "features", they increase it even more - mainly because they make it hard to modify the encrypted data.

No Filename initialization vector chaining
When filename initialization is enabled, you can copy an encrypted file from folder A to folder B and the filename is still decrypted properly. With this feature, this is not possible anymore.

No per-file initialization vectors
Right now, every file has the same deterministic initialization vectors. You can copy one block of an encrypted file at the same location in another encrypted file or tell if two encrypted files are identical.

No external IV chaining
With external IV chaining, the data in a file becomes tied to its filename. E.g. if you rename an encrypted file outside of EncFS, the data will no longer be decryptable.

No block MAC headers
With block MAC headers, it is possible to detect if an encrypted file has been modified outside of BoxCryptor.

No per-block random bytes
A special setting regarding the per-file initialization vectors.

You can find more detailed information in the EncFS man page (under "Filesystem options"):
http://pwet.fr/man/linux/commandes/encfs

So these "features" can increase the security, but even without them BoxCryptor offers great security for your private data. Decrypting your files without the correct key is impossible*. Of course, we always want to even increase this level of security and implementing these "features" is on our todo-list!

I hope I could answer your questions.

* It is important to know, that every encryption can be broken if you just have enough time and/or resources ("It is theoretically possible to break such a system but it is infeasible to do so by any practical means." Wikipedia).

jhsnyder

Robert, what you wrote amounts to:

"providing open-source encfs default capabilities would be render boxcryptor less convenient for our users."

That may (or may not) be true, but is the value of your product convenience? Or is the point secure data storage? Speaking only for myself, I find Boxcryptor no more convenient than open-source encfs.

You say that "every encryption can be broken" (not quite true!) and make the (valid) point that brute-forcing AES encryption may be unfeasible.

But encryption can be broken in many ways. Successful attacks generally do not employ brute-force, as you must know. WEP was not brute-forced, for instance.

You wrote: "decrypting your files without the correct key is impossible". This is true (AFAIK) but irrelevant. A more relevant concern is: "how difficult to obtain the key?"

In your response to meinusername you say that Boxcryptor does not support per-file IV, nor IV chaining etc. These capabilities are used by default in open-source encfs.

I just downloaded Boxcryptor 1.3.2.0 (the free version), and am disappointed to find that I cannot read my Linux-encfs-encrypted files on Windows. I used default encfs settings on Linux.

Does Boxcryptor plan to implement the *default* features of open-source encfs that Boxcryptor does not currently support?

If so, would you be so kind as to let us know the timeline for that implementation?

Thanks for your interest.

Geronimo

jhsnyder, you might be interested in the conversion I had about nine months ago concerning almost the same topic (https://forums.boxcryptor.com/topic/implementation-of-encfs-features#post-165). In brief the follwoing answer I got at that time points out
the direction the developer team has :

"Basically, BoxCryptor is not and will not be a Windows port of EncFS. Although our goal is to support all *important* features of EncFS and to have great EncFS compatibility, we will never offer full 100%. Our vision for BoxCryptor is something "bigger" and even though EncFS works good with cloud storage, it is not *optimized* for this use case."

As far as I understand Boxcryptor development is partly driven by user voting for new features. If you browse http://boxcryptor.uservoice.com and search for EncFS you find
an entry called 'Provider better EncFS compatibility', with (including mine) just seven votes.

Sad but true, to my view Boxcryptor misses the chance to go beyond and become 'the' windows port of EncFS. Moreover, the EncFS roots are not advertised at all although it could be a good strategy, as EncFS's security is proven due to it's open-source status.
By the way I always found it interesting how this works legally : despite of all improvements the core idea & mechanism, coded from scratch again or not, was invented by someone else under the GPL license which apparently permits such a commerical utilization. The original developer is not even credited, well, well

So, in fact we've got the choice : a free version, the EncFSWin port which offers all features but still fails with regard to reliability etc, and a (so far) well developed 'bigger' vision which is a somehow crippled EncFS port when it comes to core functions (not to forget Blowfish). The question what is regarded as an 'important feature' is up to the company, regrettably better compatibility is not.