>>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. ------------------------------------------------------------------------------ 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
