[tahoe-lafs-trac-stream] [tahoe-lafs] #2018: padding to hide the size of plaintexts

[tahoe-lafs]

#2018: padding to hide the size of plaintexts
-------------------------+-------------------------------------------------
     Reporter:  zooko    |      Owner:  nejucomo
         Type:           |     Status:  new
  enhancement            |  Milestone:  undecided
     Priority:  normal   |    Version:  1.10.0
    Component:  code-    |   Keywords:  confidentiality privacy compression
  encoding               |  newcaps research
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------
Description changed by zooko:

Old description:

> Even though LAFS keeps the contents of files secret from attackers, it
> currently exposes the length (in bytes) of that content. This can be
> useful information to an attacker in various ways. For one thing, an
> attacker might be able to "recognize" specific files or kinds of files
> from a pattern of file sizes. More subtle dangers may also exist,
> depending on the circumstances, for example the famous "CRIME" attack on
> SSL (http://security.stackexchange.com/questions/19911/crime-how-to-beat-
> the-beast-successor/19914#19914) which depends crucially on the attacker
> being able to measure the exact size of certain encrypted output. Ticket
> #925 is about how potentially interesting metadata about the LAFS
> filesystem itself can be inferred from the byte-level granularity of
> exposed sizes.
>
> I propose that LAFS automatically add a randomized number of padding
> bytes to files when encrypting. Concretely, how about something like
> this. With {{{F}}} as the file size in bytes,
>
> 1. Let the "max padding", {{{X}}}, be {{{32 * log₂(F)}}}, rounded up to
> the nearest multiple of 32.
>
> 2. Choose a number of padding bytes, {{{P}}}, evenly from {{{[0..X)}}} as
> determined by the encryption key. ''Note: this is important that the
> number is deterministic from the key, so that multiple encryptions of the
> same-keyed file will not pick different random numbers and allow an
> attacker to statistically observe the padding's size.''
>
> 3. Append {{{P}}} bytes of padding (0 bytes) to the plaintext before
> encryption. (This does not affect how the key is derived from the
> plaintext in the case of convergent encryption.)

New description:

 Even though LAFS keeps the contents of files secret from attackers, it
 currently exposes the length (in bytes) of that content. This can be
 useful information to an attacker in various ways. For one thing, an
 attacker might be able to "recognize" specific files or kinds of files
 from a pattern of file sizes. More subtle dangers may also exist,
 depending on the circumstances, for example the famous "CRIME" attack on
 SSL (http://security.stackexchange.com/questions/19911/crime-how-to-beat-
 the-beast-successor/19914#19914) which depends crucially on the attacker
 being able to measure the exact size of certain encrypted output. Ticket
 #925 is about how potentially interesting metadata about the LAFS
 filesystem itself can be inferred from the byte-level granularity of
 exposed sizes.

 I propose that LAFS automatically add a randomized number of padding bytes
 to files when encrypting. Concretely, how about something like this. With
 {{{F}}} as the file size in bytes,

 1. Let the "max padding", {{{X}}}, be {{{32*ceil(log₂(F))}}}.

 2. Choose a number of padding bytes, {{{P}}}, evenly from {{{[0..X)}}} as
 determined by the encryption key. ''Note: this is important that the
 number is deterministic from the key, so that multiple encryptions of the
 same-keyed file will not pick different random numbers and allow an
 attacker to statistically observe the padding's size.'' Be sure the pad
 length gets derived from the key via a strongly one-way path.

 3. Append {{{P}}} bytes of padding (0 bytes) to the plaintext before
 encryption. (This does not affect how the key is derived from the
 plaintext in the case of convergent encryption.)

--

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2018#comment:13>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage