2014-02-24 1:20 GMT+01:00 Anthony Thyssen <a.thys...@griffith.edu.au>:
> 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.
>
Thank you for your answer Anthony !
Yes, a single extra block at the start is what I was thinking about when I
said to grow the header to the exact size of a block.
And you're right, to limit the overhead on small files, we could use the
extra free space of this header block to store the file, of course only if
the file size is lower than or equal to the extra free space.
If the file is bigger than the extra free space, it must starts at the
beginning of the second block, to be sure to have IOs aligned.
In this case, we would loose this extra space, this is why I was thinking
about moving the header to the end of the file.
However, it could lead into a performance impact, the disk would have to
seek to the end of the file before going back to its start to read it...
To be sure that all IOs of one file will be aligned, does the encryption of
4K of data give exactly 4K of encrypted data ?
I think it could be interesting, in terms of performance, to have IOs
aligned.
Don't you ?
Should we open a feature request ?
Thank you !
Ben
------------------------------------------------------------------------------
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
