Information leak to holders of a directory read cap, about whether each dir entry is writeable

[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 could address that by making _unpack_contents strip spaces from the front and end of the decrypted rw_uri, for example. That would potentially allow some future version to pad the URI with spaces to a fixed length.