id summary reporter owner description type status priority milestone component version resolution keywords cc launchpad_bug 2018 padding to hide the size of plaintexts zooko nejucomo "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.) " enhancement new normal undecided code-encoding 1.10.0 confidentiality privacy compression newcaps research nejucomo@… me+tahoetrac@…