2013/12/23 Frediano Ziglio <fredd...@gmail.com>
> 2013/12/23 Ben RUBSON <ben.rub...@gmail.com>:
> > 2013/12/20 Anthony Thyssen <a.thys...@griffith.edu.au>
> >> On Thu, 19 Dec 2013 23:21:03 +0000 Frediano Ziglio <fredd...@gmail.com>
> wrote:
> >> | 2013/12/19 Ben RUBSON <ben.rub...@gmail.com>:
> >> | > Hello,
> >> | >
> >> | > Here is a topic about Filename Initialization Vector Chaining.
> >> | >
> >> | > I do not use it because I have directories with a huge amout of
> >> subdirectories and files, so I do not want to be impacted by the
> significant
> >> performance impact which directory renames involve.
> >> | >
> >> | > Could we think about a solution to give each object's name its own
> >> initialization vector but not based on its path ?
> >> | > This would help with the performance impact.
> >> | >
> >> |
> >> | I think like files there could be a name algorithm with single IV like
> >> for file.
> >> |
> >> | > About attacks, let's assume that the attacker knows that at a
> specific
> >> location of the encoded files' tree, there is an object called
> "myfile.txt".
> >> | > For example, he now knows that "myfile.txt" gives
> >> "p5aHkU3UCjr21t6pqz0wK8zIdbHAoTqO6jdTcLcocpMNg9" once encoded.
> >> | > Can he find out the key with associations like this ?
> >> | > - without Filename Initialization Vector Chaining enabled ?
> >> | > - even with Filename Initialization Vector Chaining enabled ?
> >> | >
> >> |
> >> | Surely easier without IV chaining. But beside this I don't know any
> >> | no-brute force way to get the key from data + crypt(data). Actually
> >> | there should be no problem according to
> >> |
> >>
> http://security.stackexchange.com/questions/5355/compute-the-aes-encryption-key-given-the-plaintext-and-its-ciphertext
> .
> >> |
> >> | Considering that you can set up encfs to not encrypt names you
> >> | probably want to protect names encrypting them. If a large number of
> >> | files have the same encrypted name they are probably common names
> >> | (README, system files, SCMs or whatever) and you probably can guess
> >> | them. You can then probably infer some informations on the content.
> >> | For instance if you know that you use a Mac, and you suppose that a
> >> | common name is the thumbnail directory you can know how many images
> >> | are in a specific directory. If you don't like other people to know
> >> | such information single encryption without IV does not protect it. But
> >> | still single component name IV would fix this issue.
> >> |
> >>
> >> That is where salting comes in. With a small amount of salt even same
> >> names are all different.
> >>
> >> The Biggest problem with EncFS at this time is that the directory
> >> structure and file sizes are preserved. The next generation of a
> >> EncFS like or 'directory level' encryption, is to encrypt directories
> >> and files into a completely different directory structure.
> >>
> >> For example Large files become multiple seperate smaller files, while
> >> directories also become a special file and not a actual directory on
> >> the encrypted filesystem.
> >>
> >> That is remove the current 'meta data' information leakage.
> >>
> >> I have no idea if someone is working on this, or if it is planned,
> >> but it is the next logical step in a directory level encryption system.
> >
> >
> > Frediano, Anthony, thank you very much for your answers !
> >
> > Good to know that there is no easy way to get the key from data +
> > crypt(data).
> > However, what I understand is that with IV / salt, it will make it even
> > harder !
> > That's clearly understandable.
> >
> > The problem with IV chaining is the performance impact.
> >
> > Could it be possible to add IV to filenames' encoding, but not based on
> > their parent's path ?
> > Perhaps dealing with the IV at the beginning of the filename ? In an
> > extended attribute ? Base on the size of the file ? On its inode number ?
> > ...
> >
> > Should I open a feature request ?
>
> Definitely!
> Another setting, not compatible with others have to be added.
>
So here is the feature request !
http://code.google.com/p/encfs/issues/detail?id=190
Ben
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Encfs-users mailing list
Encfs-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/encfs-users
