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 ?
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
------------------------------------------------------------------------------
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
