#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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs