[tahoe-dev] notes from the Tahoe-LAFS Weekly Dev Call, 2012-09-11

David-Sarah Hopwood david-sarah at jacaranda.org
Tue Sep 11 19:54:29 UTC 2012


On 11/09/12 17:59, Zooko Wilcox-O'Hearn wrote:
> • topic: The compression attack on HTTPS.
> 
> (Not really relevant to Tahoe-LAFS, but interesting.)
> 
> Brian says one possible defense against this is to move your secrets from
> cookies to the URL. This makes the attack impossible unless your secrets are
> sharing a compression context with the attack.
> 
> Does anyone actually use TLS compression? Is it turned off by default? Does
> anyone configure it on? A similar attack is possible on HTTP encryption,

s/encryption/compression/

> if the higher-layer protocol includes attacker-controlled data in the payload.
> 
> This would be relevant to Tahoe-LAFS if we added compression. However,
> even if we added compression, we would never mix attacker-controlled
> data with attacker-unknown data in the same file. However, a higher-layer
> protocol might mix them.
> 
> One caveat: convergent encryption could allow compression between
> attacker-controlled and attacker-unknown data! In fact, there is a deep
> connection between the adaptive-chosen-plaintext-compression-
> violates-confidentiality ("CRIME") attack and the drewp "learn the
> remaining information" attack!

Assume that the compression algorithm specifier is included in the UEB,
so that there are no collisions between uncompressed and compressed files.
Further assume that compression is deterministic for a given algorithm (which
it would need to be to support convergence).

Then, I think there is no additional guessing attack enabled by file-level
compression: two files will converge iff they have identical contents,
convergence secret, and parameters (including compression algorithm), which
is no different than the current situation. Even with the attacker sharing
a convergence secret, it is no different from the corresponding case now.

> The drewp defense -- the Added Convergence Secret -- is exactly the thing
> that creates independent compression contexts in order to limit the scope for
> attack.
> 
> Zooko and (perhaps to a lesser degree) Brian are uncomfortable with the fact
> that LAFS currently exposes the length of your plaintext, to the byte level
> of precision. Zooko wants to add padding. That would probably help against
> the convergent-encryption-based CRIME attack which currently exists in hazy
> nascent form in Zooko's mind.

I'm not sure it does; the attacker would just arrange for the compressed
length to be near a block boundary, so that a change in pre-padded length
of one byte (which is all that the compression attack needs) would result
in a different number of blocks.

Note: we should distinguish between the CRIME attack and the compression
attack proposed by Thomas Pornin and described at
<http://security.blogoverflow.com/2012/09/how-can-you-protect-yourself-from-crime-beasts-successor/>,
in case they are different.

> Also, it enhances general privacy, for example
> an attacker might be able to recognize what files you are storing and reading
> just from the lengths of the files. Padding could help against that. Padding
> out to fixed boundary (e.g. to the next 16 bytes, or to the next 4096 bytes,
> or whatever) helps but the information can still leak if there are a number
> of files. For example, suppose you're browsing or downloading a directory
> containing hundreds of files of varying lengths. The attacker knows the
> lengths of some files that he suspects you might be browsing. Even if the
> ciphertext is padded out to fixed sizes, thus "coarsening" or discretizing
> the information, he might still be able to recognize the pattern. A better
> defense is to add a random amount of padding, where the random amount is
> determined by the (possibly convergently generated) encryption key.

That might help. If the victim can be made to generate many distinct files
containing the target secret, the random noise can be removed by averaging,
but it does make the number of files needed for the attack larger.

> Ideally, the revision history tells a story.
> 
> • topic: When do we kill off darcs?
> 
> David-Sarah still has some patches that need to be darcs pushed. But they
> could diff-and-patch those to git.
> 
> At some point soon we'll all agree to stop pushing patches into darcs.
> 
> LeastAuthority.com's Cloud Backend is currently in darcs. We are scheduled to
> merge the cloud backend to trunk within three weeks.
> 
> There is still the question of how to handle hyperlinks into
> https://tahoe-lafs.org that point at darcs patches and history.

I think that the darcs history should be retained as read-only, but
'darcs annotate' switched off to avoid performance problems on tahoe-lafs.org.
(We can remove obsolete darcs branches.)

> • topic: Will Cloud Backend, leasedb, and accounting go into Tahoe-LAFS v1.11?

We don't need to decide that yet, it depends whether they are ready. But it
would be really nice if they did.

-- 
David-Sarah Hopwood ⚥

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 554 bytes
Desc: OpenPGP digital signature
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20120911/f1b4dc10/attachment.asc>


More information about the tahoe-dev mailing list