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

New Issue

tahoe-lafs · 2010-01-22T08:11:13Z

davidsarah commented

2010-01-22 08:11:13 +00:00

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

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

tahoe-lafs added the

labels 2010-01-22 08:11:13 +00:00

tahoe-lafs added this to the undecided milestone 2010-01-22 08:11:13 +00:00

davidsarah commented

2010-01-22 18:05:41 +00:00

Discloses only "information other than file contents."

davidsarah commented

2010-01-23 13:19:02 +00:00

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.

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 commented

2010-01-27 20:37:14 +00:00

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.

Replying to [davidsarah](/tahoe-lafs/trac-2024-07-25/issues/925#issuecomment-74952): > 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 commented

2010-03-09 19:14:37 +00:00

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.

tahoe-lafs modified the milestone from undecided to 2.0.0

2010-03-09 19:14:37 +00:00

tahoe-lafs changed title from ~~Information leak to holders of a directory read cap, about whether each dir entry is writeable~~ to Information leak to holders of a directory read cap, about whether each dir entry is writeable and the length of its write cap

2010-04-08 02:10:37 +00:00

zooko modified the milestone from 2.0.0 to 1.10.0

2011-08-12 04:47:06 +00:00

zooko commented

2011-08-12 17:53:12 +00:00

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

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

zooko modified the milestone from 1.10.0 to eventually

2011-08-12 17:53:12 +00:00

davidsarah commented

2011-08-12 23:41:12 +00:00

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.

Replying to [zooko](/tahoe-lafs/trac-2024-07-25/issues/925#issuecomment-74958): > 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 commented

2011-08-13 04:14:28 +00:00

Replying to [davidsarah]comment:10:

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.

Replying to [davidsarah]comment:10: > 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 commented

2013-07-07 23:18:41 +00:00

See also #2018, about padding of file contents.

tahoe-lafs modified the milestone from eventually to 1.12.0

2014-12-06 14:35:41 +00:00

tahoe-lafs added

normal

and removed

minor

labels 2014-12-06 14:37:12 +00:00

warner commented

2016-03-22 05:02:25 +00:00