[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:              
---------------------------------+------------------------------------------
Changes (by asn):

  * status:  assigned => needs_review


Comment:

 Replying to [comment:5 nickm]:
 > Looks  better.
 >
 > Yeah, my rationale for allowing arbitrary shared secrets is that we
 might want to have a C API in the future, and not just have this used
 through the command line.
 >
 > Once the iterated hashing and spec changes in, let me know and I'll
 merge.  I'll arbitrarily suggest something like 100,000 SHA256 iterations.

 Done. Check my branch.

 I'll now do a break while bikeshedding pondering on the '100,000 SHA256
 iterations':

 PKCS!#5 loosely recommends more than 1000=10^3^ iterations.
 According to [http://blog.crackpassword.com/2010/12/cracking-blackberry-
 backups-is-now-slower-but-still-possible-thx-to-gpu-acceleration/ this],
 iOS3 was doing 2*10^3^ iterations, iOS4 is doing 10^4^ iterations and
 blackberry is nowadays doing 2*10^4^ of them.

 A BFMI attacker in our case not only has to do the SHA256 iterations but
 afterwards also has to apply an AES-CTR-128. I think that your 10^5^
 suggestion sounds like a safe choice with the current standards. Of
 course, it's 'easy' to make it customizable as well.

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