Re: [Encfs-users] Secrecy Proposal

[Blumenthal, U. - 0. - M. <ur...@ll...>]

>>Doesn’t EncFS obscure at least some metadata (besides names)?
>As far as I know, EncFS keeps the metadata (i.e. permission bits)
>unencrypted.

I see. Yes, I think this is correct, at least regarding permission bits.

>It obscures file names, but not file sizes or directory structure.

Well, it can confuse somewhat file size of multiple small files, but in
general you’re correct. If you have a distribution pattern (a few files of
1+MB, one file < 1KB, and a few around 100KB) it would be distinguishable.
And you described how it could be used to tell whether it’s likely to be,
e.g., a copy of CD, or a copy of Win distro, etc.

I’m not certain it would carry much harm - “yeah it was a CD, so what”,
but your point is well-taken. It would be nice to be able to hide this
kind of metadata.

As I said, I’m concerned of the cost to reliability and other capabilities
(such as multi-user access) that this measure would exact. (See below)

>A watermarking attack is where an attacker gives you a certain file (or
>set of files) and wants to check later whether you stored it in your
>filesystem or not. With EncFS, this is possible if they just remember
>the file size distribution.

I see. Thanks for explaining.

On the other hand, unless the filesystem is actively in use, I think this
attack is still possible: I observe the state, make you store a file, and
notice if the state changed or not. I don’t need to know the hierarchy to
tell that.

>> My concern is that in the attempt to improve security we may hurt
>> reliability.
>As of today, I wouldn't recommend CryFS for production use. It is a very
>young project.

Yes. I’m not talking about immaturity (i.e., bugs present and waiting to
be found and remedied). I’m talking about design decisions and their
consequences. For example, one obvious drawback is limitation on
multi-user access. 

> I'm using it myself for my documents and files and didn't
>have any issues, but it still needs to be proven by a larger number of
>beta testers. That is another reason why I reached out to this mailing
>list.

Good point.

>The design of CryFS is not very complicated and there are an awful lot
>of test cases, so I think I can get CryFS to be at least as stable as
>EncFS is today.

I can’t see why not.

With the exception of those constraints that your directory structure
maintenance would impose, of course - of which multi-user access is the
most obvious one.

>>>> For those who’d rather have a completely opaque container, there is
>>>> VeraCrypt.
>Ah right I forgot the VeraCrypt point you mentioned.
>VeraCrypt is a great choice if you're encrypting your files only locally
>and you know a maximal file system size in advance. Because you have to
>allocate a full container file even if it is only half full, you get the
>additional advantage of hiding how much data you actually store in your
>container. With CryFS, you can also do that, but it is more complicated
>(you'd have to introduce dummy blocks or a second file system with dummy
>data working on the same base directory). So for local-only encryption,
>CryFS only has an advantage if it is important to you that the file
>system only allocates the space you actually use.

Yes, it is a significant advantage, and the main reason I’m using mostly
EncFS (so far :).

>However, VeraCrypt doesn't work well when the data is stored in the
>cloud. Even if you only change one small file in your file system, this
>might cause the whole container file to be re-uploaded.

I’m not sure this is correct. For example, one could mount it as a file on
EBS or EFS.
Only if it has to be copied to the local filesystem and back, it becomes
as bad as you describe.

>Furthermore, if 
>you make changes to your file system on two different computers without
>waiting for a full sync in between, you will end up having conflicts in
>the container file, i.e. you will have two container files with each of
>them containing only one of the changes.

Yes, that’s a definite drawback.