On 4/5/17 5:32 PM, Martin Thomson wrote:
On 6 April 2017 at 06:47, Robert Sparks <rjsparks@xxxxxxxxxxx> wrote:
My only concern is that the document suggests it would be ok to use a
counter to provide a unique salt value
for each message. I suspect that provides the kind of information leak
the draft discusses avoiding.
Hi Robert, can you explain what sort of leakage you are concerned
about? I mean, I can understand how you could construct the sequence
of resources that were encrypted using a counter for the salt, but I
don't know what that might imply.
Things like these:
- A third party that could see that sequence would know if there were gaps.
- If creation or transmission time can be approximated (perhaps via file
stats),
the third party can more quickly assess the rate of creation, and
have a strong
idea of when to look for the next one.
Of course for both of those, the 3rd party would need to somehow know the
content came from the same source, but it's easy to see systems built
using this
that would expose that.
That said, I think that the counter thing can be removed. We require
128 bits of salt, which is a space that is large enough to select
randomly from in perpetuity.
That would be my personal preference.