[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #3202 [Pluggable transport]: shared secret support in obfs2
#3202: shared secret support in obfs2
---------------------------------+------------------------------------------
Reporter: asn | Owner: asn
Type: defect | Status: needs_review
Priority: normal | Milestone:
Component: Pluggable transport | Version:
Keywords: | Parent:
Points: | Actualpoints:
---------------------------------+------------------------------------------
Comment(by nickm):
I don't think I agree with having the shared secret be NUL-terminated in
the protocol level. It's fine to only take C strings from the command
line, but why limit the code by making it unable to handle something the
protocol allows fine?
Also, it seems silly to just take the thing from the command line and
shove it into the "secret" part of the protocol directly, truncating its
later bytes. Instead we should hash it so that every byte of input
counts, and the input doesn't need to be a given length. Maybe we should
even do an iterated hash approach to slow down password-guessing attempts.
(Also, the time to change stuff is now: since our hash function is 32
bytes, let's make the shared secret get to be 32 bytes long.)
Also, why not copy the secret into the state? Keeping a pointer around to
it and requiring that it never change or get freed seems like an iffy
interface choice.
Also the only code I see here sets lsn->have_shared_secret = 1
unconditionally. That's not right, is it? I'm guessing that this is
something else that you had for testing that you mean to turn off later?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3202#comment:3>
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