I'm just sort of wondering if any more progress, thoughts or discussion has happened along these lines.
It may be that such a major change would need to be created as a new project. Any info? Anthony Thyssen ( System Programmer ) <a.thys...@griffith.edu.au> -------------------------------------------------------------------------- "Yeap, I died on level twenty when my pet dragon caught a cold!" -------------------------------------------------------------------------- Anthony's Castle http://www.ict.griffith.edu.au/anthony/ On Mon, 15 Sep 2014 17:29:53 -0700, Sebastian Messmer <heinzis...@web.de> wrote : I like the idea of also hiding directory structure. I see the problem with the metadata. We could either try to implement an own representation of metadata, or just ignore it in this mode (at least at first). Since the user can decide whether to use this mode or not, they can then choose between preserving metadata or improved secrecy. In many use cases (like cloud file syncing), metadata preservation doesn't work anyhow. Even if the cloud storage is capable of storing them, it will fail when having the files on different operating systems (or different file systems for that matter). Best Sebastian Am Dienstag, den 16.09.2014, 10:30 +1000 schrieb Anthony Thyssen: > 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 ------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------ _______________________________________________ Encfs-users mailing list Encfs-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/encfs-users
