[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #7202 [Tor]: Implement ntor handshake or its successor
#7202: Implement ntor handshake or its successor
--------------------------------+-------------------------------------------
Reporter: karsten | Owner:
Type: project | Status: needs_review
Priority: normal | Milestone: Tor: 0.2.4.x-final
Component: Tor | Version:
Keywords: SponsorZ tor-relay | Parent:
Points: | Actualpoints:
--------------------------------+-------------------------------------------
Comment(by nickm):
Replying to [comment:17 mikeperry]:
> Ok, I think I've finished looking over the unit test in comparison to
the original paper. I think it all matches up now (aside from the dirauth
checking issue), but I have one nagging, basic question: Why do we
separately compute s.verify anymore now that we use rfc5869_sha256() to
derive our key material? Couldn't s.secret_input go directly into the Hmac
step and save us the verify hash, or is there additional future-proofing
against hash weaknesses hidden in this step?
I believe it's meant to be future-proofing against hash weaknesses, bad
kdfs, or stuff like that.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7202#comment:19>
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