[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #22948 [Core Tor/Tor]: Padding, Keepalive and Drop cells should have random payloads
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs