[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:
---------------------------------+------------------------------------------
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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs