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

Reply via email to