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.