Since EncFS doesn't hide directory structure (and also in the light of the recent security issues), and since the discussion on the mailing list here showed that it is probably out of scope for the original EncFS project, I've started an own project fixing this. You can find CryFS at https://www.cryfs.org Please take a look and give me feedback.
It encrypts file contents, file metadata, file sizes and directory structure by splitting everything into same-size blocks and encrypting them individually. I've analyzed and proven its security from a theoretical point of view (using game based security notions) in my Master's thesis. More information on its inner workings can be found at https://www.cryfs.org/howitworks I wouldn't declare it stable yet, but I'm using it with my own files already for some time and didn't run into problems so far. I'd be happy if you could give it a try and tell me what it could do better or (in case) what is broken. If you're interested in helping coding, I'd also be happy to hear from you. Thank you Sebastian Messmer On 16.09.2014 02:30, Anthony Thyssen wrote: > On Sun, 14 Sep 2014 22:26:34 -0700 > Sebastian Messmer <heinzis...@web.de> wrote: > | Hello, > | > | I'm using encfs for encrypted cloud file synchronization and it works > | great. I have some thoughts about secrecy though I'd like to discuss. > | > | Encfs is great in hiding file contents. If enabling file name > | encryption, you can also hide a bit more information about what the > | files contain. > | However, seeing the file size, an attacker can often guess the kind of > | files you're storing. A music collection has a certain file size pattern > | that is different from e.g. video files, a photo collection or > | documents. > | > | Other encryption systems (like truecrypt) are better in hiding what > | you're storing inside, but having one big file storing all of your data > | is not feasible in many scenarios. For example when you want to do cloud > | file synchronization, you can't use a system where you have to reupload > | the whole directory when you only changed one small file. > | > | I was thinking about how we could get this kind of secrecy in encfs > | without having this disadvantage. > | > | My proposal is to add a special encryption mode (the user can > | enable/disable it when initializing the encrypted folder), in which we > | don't encrypt single files, but bundle files together to blocks and > | store these blocks of data. The block size could be configured by the > | user. For the sake of this example, say we have a small folder with some > | vacation photos and choose a block size of 10MB. > | > | On the disk, we don't store an encrypted version of each picture, but we > | store each encrypted block as one file. So if we have 5 pictures with 3 > | MB each, they would get bundled together into two blocks and stored as > | two files of 10MB each. > | > | If we have one particularly large picture > 10MB, this file would be > | split up into multiple blocks. > | > | There is still a lot to think about on how to actually implement it. > | We'd probably have to store some metadata in the blocks to retrieve the > | actual files stored in them, which would complicate the > | encryption/decryption process a bit. But I think getting this kind of > | secrecy is worth it. And I think we could do it in a way that the > | mapping from the encrypted blocks to the decrypted virtual files stays > | relatively simple. > | > | What are your thoughts on this? Has this idea been discussed before? > | > | Thanks, > | Sebastian > | > | > I have proposed similar ideas, but not just to hide the file sizes > but also the directory structure. > > That is like 'UNIX' file systems, a directory is itself just a file > that contains the pointers matches filenames to file locations (inodes). > If this is done, files (or multiple files holding a single encrypted > file), would be stored in a directory tree that has no relation with the > original un-encrypted directory structure. if all files have a maximum > size before being split up, it is imposible to 'guess' what is in files, > especially as related parts may not even be 'grouped' by the directory > structure. > > > One problem at this time is that encfs tries to preserve > file permissions and and other directory level meta-data (times, > symbolic links, hard links, etc). This detail is not encrypted > and depends on the underlying directory store rather than the > encryption. > > When you split up files or hide directory structure, you have > to start handling this in EncFS in some way. > > > > > > Anthony Thyssen ( System Programmer ) <a.thys...@griffith.edu.au> > -------------------------------------------------------------------------- > Disclaimer: Any lapses in spelling, tact, or fact are transmission errors. > -------------------------------------------------------------------------- > Anthony's Castle http://www.ict.griffith.edu.au/anthony/ > > ------------------------------------------------------------------------------ > Want excitement? > Manually upgrade your production database. > When you want reliability, choose Perforce. > Perforce version control. Predictably reliable. > http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk > _______________________________________________ > Encfs-users mailing list > Encfs-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/encfs-users ------------------------------------------------------------------------------ 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
