Hey Uri,

On 08.02.2016 22:17, Blumenthal, Uri - 0553 - MITLL wrote:
> Well, it can confuse somewhat file size of multiple small files
That sounds interesting. Can you explain what you mean by that?
>> 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.
Yes, I agree. If the attacker has constant access to your Dropbox and 
sees the access pattern, watermarking attacks can still be possible. 
Actually, it might even be possible without constant access, because 
Dropbox keeps a file history which allows an attacker to get the access 
patterns afterwards. CryFS obfuscates this a bit better than EncFS (the 
attacker only knows that the file system grew by x bytes, they don't 
know how many files were added or how large individual files are), but 
that might be enough to get statistically relevant knowledge.
> 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. 
There is the issue in the current implementation that you can get 
conflicts when multiple users are modifying the same directory at the 
same time. This is, however, an implementation issue and not a design 
issue. If you're interested in some possible solutions, you can take a 
look at section 4.6 in https://www.cryfs.org/cryfs_mathesis.pdf .
>> 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.
Yes, if you keep the container file entirely remotely and mount it over 
the network, you might get around this issue. I'm not sure whether 
VeraCrypt can handle multiple instances accessing the same container 
file at the same time though.

As a side note, the way CryFS stores its blocks is a quite small module 
in the application that could easily be changed to directly storing it 
on EBS or S3 (or any other cloud provider). I'm thinking about offering 
a version that runs directly off the cloud without a local copy of the 
ciphertexts. This is only an idea and nothing concrete yet though.

Best
Sebastian

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Encfs-users mailing list
Encfs-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/encfs-users

Reply via email to