[tor-bugs] #22948 [Core Tor/Tor]: Padding, Keepalive and Drop cells should have random payloads

Tor Bug Tracker & Wiki blackhole at torproject.org
Sun Jul 23 00:48:15 UTC 2017


#22948: Padding, Keepalive and Drop cells should have random payloads
--------------------------+------------------------------------
 Reporter:  teor          |          Owner:
     Type:  defect        |         Status:  new
 Priority:  Medium        |      Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:  tor-spec      |  Actual Points:
Parent ID:  #18856        |         Points:  0.5
 Reviewer:                |        Sponsor:
--------------------------+------------------------------------

Comment (by teor):

 Replying to [comment:8 isis]:
 > ...
 >
 > So the defense-in-depth in this case has a lot of assumptions like: if
 we believe that AES-128 is not breakable in close-to-real-time (we do),
 and we believe that neither endpoint is victim to any kleptographic attack
 (we can't defend against that), and we don't believe that an adversary is
 capable of a SHA-256 second-preimage in any reasonable amount of time (we
 don't), then the fact that some subset of cells on a circuit have known
 plaintexts probably doesn't really give you that much of an advantage in
 terms of forging a MAC that is cumulative over all data seen so far (i.e.
 `H(a || b || c || …)` ''not'' "chained" like `H(… || H(c || H(b ||
 H(a))))`). You'd need a second-preimage on SHA-256, so finding `x'` where
 `H(x) == H(x')`.

 Unfortunately, Tor still uses SHA1 for its relay cell digests, except for
 onion service v3 client to service cells, which use SHA3-256.

 But I think your reasoning still applies, at least for the next few years.

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


More information about the tor-bugs mailing list