Re: [tor-bugs] #26846 [Core Tor/Tor]: prop289: Leave unused random bytes in relay cell payload

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#26846: prop289: Leave unused random bytes in relay cell payload
------------------------------------------+--------------------------------
 Reporter:  dgoulet                       |          Owner:  dgoulet
     Type:  enhancement                   |         Status:  assigned
 Priority:  Medium                        |      Milestone:  Tor:
                                          |  0.3.5.x-final
Component:  Core Tor/Tor                  |        Version:
 Severity:  Normal                        |     Resolution:
 Keywords:  prop289, 035-roadmap-subtask  |  Actual Points:
Parent ID:  #26288                        |         Points:
 Reviewer:                                |        Sponsor:  SponsorV
------------------------------------------+--------------------------------

Comment (by arma):

 Replying to [comment:3 arma]:
 > and somebody should check my logic but I think a rare but unpredictably
 short payload with a zero is enough to accomplish our goal here -- that
 is, we don't actually need a random byte, we just need to have it be
 unpredictable when the 0 will appear.

 Ok, I have two counterexamples that make me resume thinking we need the
 unused portion of the payload to be random. The first counterexample is
 sort of ugly and it's unclear how practical it is as an attack, but the
 second counterexample is elegant and simple.

 The first one is: what if the source of bytes at the destination side
 sends bytes out 400 at a time? Then we would always package them up 400 at
 a time, and we would never trigger the "decrement the length" function,
 because we would always only have partially full payloads anyway. Now,
 this isn't *so* bad for two reasons. One is that if you wanted to be sure
 to separate your 400 byte chunks so they go in different cells, you're
 really slowed down on the rate you can generate new cells. And the other
 related reason is that maybe the exit will package them in a different way
 than you expect, like 200 at a time every so often, or it will clump
 together two of your 400's sometimes, or etc. But still, I think this
 attack could work 'sometimes', and that is worrisome. It would be fixed by
 making the unused portion of the relay data cell payload random.

 And the second attack is: what if the destination is sending a stream of 0
 bytes? Then our payloads consist of NUL bytes, and every so often we make
 a short payload and put a NUL at the end. And our security relies on the
 attacker not being able to guess which bytes will be padding ("0") and
 which ones will be in-use-payload (also "0"). Oops. This attack would also
 be fixed by making the unused portion of the relay data cell payload
 random.

 I think this logic argues for another subticket on #26288: "randomize the
 unused part of relay payloads".

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/26846#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs