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

[Zooko Wilcox-O'Hearn]

Folks:

As usual, I'm not taking the time to contextualize and vet all these
notes. Caveat lector! Also, I've maintained my tradition of adding
some of my own thoughts that weren't actually expressed out loud in
the discussion. (In particular the advocacy for adding padding and the
ideas about how to do so.)


in attendance: Brian, David-Sarah, Andrew, Zooko (scribe)

b" 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, 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!

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. 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.

b" topic: engineering tools and practices

We talked about usage of git. David-Sarah likes git-gui. Andrew asked if he
should rebase patches when submitting pull requests and Brian said yes. Brian
said always first rebase -- bring everything up to trunk -- and then rerecord
it as a set of logical commits. It is not necessary to squash it all down
into a single commit, unless that's what makes sense. Definitely squash out
ephemeral stuff like "Oops, made a typo, oops test didn't pass, let me go
back and fix that.". It often makes sense to make four patches: First
refactor the code so that there is no actual functional changes, second
cosmetic changes like whitespace, third update the unit tests, fourth the new
code.

Ideally, the revision history tells a story.

b" 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.

b" topic: Will Cloud Backend, leasedb, and accounting go into Tahoe-LAFS v1.11?
_______________________________________________
tahoe-dev mailing list
tahoe-dev at tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE