[tahoe-lafs-trac-stream] [tahoe-lafs] #925: Information leak to holders of a directory read cap, about whether each dir entry is writeable and the length of its write cap

[tahoe-lafs]

#925: Information leak to holders of a directory read cap, about whether each dir
entry is writeable and the length of its write cap
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:
  davidsarah             |     Status:  new
         Type:  defect   |  Milestone:  eventually
     Priority:  minor    |    Version:  1.5.0
    Component:  code-    |   Keywords:  backward-compatibility privacy
  dirnodes               |  security
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Old description:

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

New description:

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

--

Comment (by zooko):

 See also #2018, about padding of file contents.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/925#comment:12>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage