[tahoe-dev] proposal: add padding

[Callme Whatiwant]

I propose: don't do anything without both a threat model and a clear
picture of the trade-offs any defense feature introduces.


Example conflict of goals: efficiency in the form of range updates
(which I believe MDMF format implements?) versus confidentiality
(against what threat model?) in the form of random padding.


Let's say you have a fancy loop-back encrypted filesystem with all
your precious secrets, and it is backed by LAFS, and you edit a file
inside the loopback filesystem to update a small secret.  Does this
translate into an efficient range update request in LAFS, of which a
storage operator can see the size and deduce the secret size?

Suppose the small secrets are changes to directory links.  Now can the
storage operator learn your directory structure over time, even though
you have both a loop-back encrypted filesystem on top of LAFS
confidentiality measures?

Would you want to re-upload the entire N gigabyte loopback filesystem
on each update in order to protect confidentiality at this
granularity?


If we have a clear threat model, then we can have a clear instruction
for users, such as: "If you can't tolerate the risk of a single
storage node operator learning the directory structure of an encrypted
loopback filesystem over time, then disable the range requests
feature."


regards,
nejucomo

ps: I say basically the same on the ticket:

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2018#comment:6

On Thu, Jul 18, 2013 at 2:34 PM, Nico Williams <nico at cryptonector.com> wrote:
> On Wed, Jul 17, 2013 at 9:27 PM, Pierre Abbat <phma at bezitopo.org> wrote:
>> On Friday, July 12, 2013 16:56:47 Zooko O'Whielacronx wrote:
>>> No, no, we rely on the correctness of our encryption to hide all
>>> information about the plaintext from an attacker who doesn't know the
>>> encryption key. Therefore, the pad bytes are all just zero bytes, and
>>> we believe that this pattern gives nothing useful to the cryptanalyst.
>>
>> Encrypting padding consisting of all zero bytes creates a known-plaintext
>> attack. The padding should be the output of a CSPRNG whose seed is determined
>> by the contents of the file.
>
> No, because first of all the attacker doesn't know the plaintext (they
> can guess as how much padding there is, and then guess that much of
> the plaintext), and second because it's not chosen plaintext (not
> chosen by the attacker), and third because AES is supposed to leak
> nothing much about either the key nor the rest of the plaintext of a
> given block just because you happen to know some of the plaintext (or
> even all).
>
> Nico
> --
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev