>>Well, it can confuse somewhat file size of multiple small files >That sounds interesting. Can you explain what you mean by that?
I meant that since file size does change with encryption padding, MAC, and IV - if (a) one picks large block size, and (b) filesize are comparable to block size, it would be hard to tell one (small) file from another. Think copies of text emails (not those JavaScript monsters :). :-) >> 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. >> 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 . Let me take a look and get back to you. >>> 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. This is the ideal use of the cloud storage. I realize that it isn’t always possible. :-( >I'm not sure whether >VeraCrypt can handle multiple instances accessing the same container >file at the same time though. I don’t know (yet). >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. I think it would be *very* nice to have this option/capability. ------------------------------------------------------------------------------ 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
