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. > http://code.google.com/p/encfs/issues > (according to source changes, project is still alive, Valient has made a lot > of updates since last release 1.7.4). > > Thank you very much ! > > Best regards, > > Ben > Frediano ------------------------------------------------------------------------------ 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
