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.
Anthony Thyssen ( System Programmer ) <a.thys...@griffith.edu.au>
--------------------------------------------------------------------------
Stepped out for a byte! Back soon.
--------------------------------------------------------------------------
Anthony's Castle http://www.ict.griffith.edu.au/anthony/
------------------------------------------------------------------------------
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
