Information leak to holders of a directory read cap, about whether each dir entry is writeable and the length of its write cap

[davidsarah]

The encryption of the rw_uri of a dirnode with the writekey of its directory is done in CTR mode, and is length-preserving (excluding the added salt and MAC tag which are fixed-length). This leaks the length of the plaintext rw_uri to a holder of the directory read cap. This is a relatively minor information leak, but it does reveal whether the object pointed to by each dirnode entry would be writeable to someone with the directory write cap -- if not then the ciphertext excluding salt and MAC will be zero-length.

(The directory readcap holder necessarily knows whether or not the object pointed to by the dirnode entry is mutable -- but if it is, then they don't have any need to know whether it is writeable.)

Padding to a fixed length could solve this, but there would be a backward-compatibility problem, because the padding would break earlier storage clients who wouldn't be expecting it. Starting from Tahoe-LAFS 1.6, we have addressed that by making _unpack_contents strip spaces from the end of the decrypted rw_uri. That potentially allows some future version to pad the URI with spaces to a fixed length (breaking only clients of versions before 1.6).

[davidsarah]

Discloses only "information other than file contents."

[davidsarah]

The patch for #833 now implements the 'strip spaces from the front and end of the decrypted rw_uri' suggestion, since that code needed to change anyway.

[davidsarah]

Replying to davidsarah:

The patch for #833 now implements the 'strip spaces from the front and end of the decrypted rw_uri' suggestion, since that code needed to change anyway.

I'm going to change this to strip spaces only from the end. Stripping them from the front would have an unnecessarily confusing interaction with prefix checks.

[davidsarah]

The forward-compatibility part of this issue is fixed -- 1.6.0 strips spaces from the end -- but we can't break backward-compatibility yet.

[zooko]

I briefly put this ticket into the 1.10 Milestone, but then I realized we don't want to break backwards compatibility with Tahoe-LAFS v1.6, because it ships with Ubuntu 10.04 Lucid:

​http://packages.ubuntu.com/search?keywords=tahoe-lafs&searchon=names&suite=all&section=all

Lucid is an Ubuntu "Long Term Stable" release, is supported by the Ubuntu project and/or Canonical until 2015, and in all likelihood will be widely used at least until then. We should be cautious about making any change that breaks backward compatibility with Tahoe-LAFS v1.6.

Moving this ticket to Milestone "eventually".

[davidsarah]

Replying to zooko:

I briefly put this ticket into the 1.10 Milestone, but then I realized we don't want to break backwards compatibility with Tahoe-LAFS v1.6, because it ships with Ubuntu 10.04 Lucid:

​http://packages.ubuntu.com/search?keywords=tahoe-lafs&searchon=names&suite=all&section=all

The forward compatibility fix was in Tahoe v1.6.0. Only versions *before* that would be broken.

[zooko]

Replying to davidsarah:

The forward compatibility fix was in Tahoe v1.6.0. Only versions *before* that would be broken.

Oh, good! I remember you and I caring a lot about forward-compatibility back then, and now I'm glad we did. :-)

I'm happy to drop backward-compatibility with Tahoe-LAFS older than v1.6.

[zooko]

See also #2018, about padding of file contents.

[warner]

Milestone renamed

[warner]

renaming milestone

[exarkun]

Moving open issues out of closed milestones.

[meejah]

Ticket retargeted after milestone closed