[tor-bugs] #3202 [Pluggable transport]: shared secret support in obfs2

[Tor Bug Tracker & Wiki]

#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