Re: [Encfs-users] Secrecy Proposal

[Jakob U. <jak...@gm...>]

Hi Sebastian, great work, congratulations!
I tested it briefly and only found two minor issues that I have reported
through github.

However, I don't yet understand how Dropbox synchronisation is supposed to
work.

As far as I can see, the list of files in a directory is stored in a file.
So if Alice creates "file1" while Bob creates "file2", this will cause a
synchronisation conflict on the directory file, right?

Best regards,
Jakob

On Fri, Feb 5, 2016 at 9:06 PM, Sebastian Messmer <hei...@we...> wrote:

> 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 <hei...@we...> 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.
> >
>