2014-02-27 16:30 GMT+01:00 Taylor Hornby <ha...@defuse.ca>:
> On 02/23/2014 10:43 AM, Ben RUBSON wrote:
> >> > So, a solution could to use a block instead of a stream for the last
> (partial) data block.
> >> > The last partial block could be padded with random bytes, zeros…
> >> > I don’t know wether number of blocks used in a file is stored in its
> EncFS header or not, but if it is, it could be replaced by its size, so
> that the end of the file data in the last block is known.
> >> > Stream mode would then not be used at all, which would solve issues
> 2.2 and 2.3.
> >> >
> >> > It would also solve reference [2] as encoded files' size would not be
> the real files’ size but a multiple of the block size.
> >> > By "chance" it could be the real files' size, but not necessarily.
> >
> > Taylor, do you think it could be a solution ?
>
> Sorry for not replying. I forgot I had this list automatically going
> into a different folder!
>
No problem at all, thank you for your answer !
> Something like that could be a solution, but I'm hesitant to recommend
> it because there's lots of ways it could go wrong, and it's not
> something cryptographers have analyzed very well. I'd rather stick to
> the well-tested standard, which is XTS mode. But... if XTS mode
> absolutely isn't an option, then something like that would be possible,
> but it would need a good amount of thought.
>
> It wouldn't solve the file size disclosure issue, since you could still
> know files' real size to an accuracy of 16 bytes. That's still accurate
> enough to do fingerprinting.
The file could be padded up the end of the last disk block.
On 4K block filesystems, it would randomize the file size from 0 (the file
is exactly n x 4K) to 4095 bytes (the file is n x 4K + 1 byte).
Perhaps file size would then have to be stored somewhere.
Not sure it is really needed, but if it is, it could be stored (encrypted)
in the header block proposed in this enhancement :
https://code.google.com/p/encfs/issues/detail?id=195
(however perhaps that storing the file size at the beginning of the file
could cause a performance impact if the size needs to be written /
updated... while managing the last block of the file ; this would have to
be implemented properly to avoid disk seeks).
A benefit of this padding is that block mode would then be easily usable on
all the file, stream mode wouldn't have to be used anymore.
Well, this is another enhancement I was thinking about :-)
Best regards,
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
