On Sun, 23 Feb 2014 19:00:16 +0100 Ben RUBSON <ben.rub...@gmail.com> wrote: | > According to the EncFS presentation, page 33 : | > http://www.arg0.net/encfs-presentation.pdf | > | > From what I understand, if an application reads a 512 bytes data block, and if MAC (authentication code) is enabled, alignment with disk blocks will not be preserved, and 2 blocks will be read from the disk, "instead" of one. | > Same thing of course if we talk about 4K data blocks on 4K block disks. | > So for alignment / performance purpose, authentication code should be turned off, as random bytes (0). | > This is the default configuration. | > | > What about per-file initialization vectors ? | > Per-file IV adds a file header (in which the IV is stored), leading into non-aligned IOs. | > However, per-file IV seems to be a must-have for security reasons. In addition, default configuration enables this option. | > | > So could we think about a solution to keep IOs aligned even with per-file IV option enabled ? | > Growing the header to the exact size of a block (512b, 4K... depending on the configured block size) ? | > Moving header at the end of the file, in the last data block (last block would then be data;padding;footer) ? | > Any other solution ? | > | > Is there any other EncFS configuration option (except MAC, random bytes and per-file IV) that would lead into non aligned IOs ? | | Hello, | | Any comment on this topic ? | Valient ? :-) | | Thank you very much ! | | Ben |
How about having every file have a single extra block at the start. this block contains per-file IV data, and perhaps even per block data (optional). Per block data would mean that there is a limit to how much block data can be stored in that single per-file block. However I would also start looking at splitting up longer files into multiple files of different names. This removes on of the other 'failures' of EncFS, file length. You can often tell that this directory is all images, and this is all video, and this is all music, simply by file lengths. Splitting up files into multiple files will remove that information. Directories also could become encrypted files rather than real directories. It would probably make directory listing faster too as EncFS no longer needs to try and decrypt every filename in a directory to get a directory listing, and would remove the directory structure information from EncFS. Anthony Thyssen ( System Programmer ) <a.thys...@griffith.edu.au> -------------------------------------------------------------------------- Real Science:- That is to say, the sort you can use to give something three extra legs and then blow it up. -- Terry Pratchett, "Feet of Clay" -------------------------------------------------------------------------- Anthony's Castle http://www.ict.griffith.edu.au/anthony/ ------------------------------------------------------------------------------ Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk _______________________________________________ Encfs-users mailing list Encfs-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/encfs-users
