[tor-bugs] #11093 [Obfsproxy]: obfsproxy should use C implementation of UniformDH

[Tor Bug Tracker & Wiki]

#11093: obfsproxy should use C implementation of UniformDH
---------------------------+-----------------
     Reporter:  asn        |      Owner:  asn
         Type:  defect     |     Status:  new
     Priority:  normal     |  Milestone:
    Component:  Obfsproxy  |    Version:
   Resolution:             |   Keywords:
Actual Points:             |  Parent ID:
       Points:             |
---------------------------+-----------------

Comment (by yawning):

 Just to clarify this a bit, the gmpy (gmpy2) implementations are about as
 fast as the OpenSSL code I have (with a slight advantage to the gmpy code
 for key generation because I  *always* generate 2 public keys to avoid
 exposing which one is chosen), but the OpenSSL code I have applies
 blinding.  I could get a faster implementation but the main gain is that
 it's more resistant to timing attacks.

 If using OpenSSL is acceptable, then #11050 should be solved as well
 (either by switching from PyCrypto to M2crypto, or perhaps by extending
 the module I wrote to cover all of the cryptography required for
 obfsproxy).  The latter approach would also allow better management of key
 material since the shared secret/session keys don't ever need to be seen
 by the actual python code, so I think it may be better from a paranoia
 stand point, but the downside is that someone would need to write the
 code.

 I do note that ensuring data integrity/secrecy once the transport is known
 (at the point people are exploiting these problems) is outside of the
 obfs3 threat model, but it still feels sloppy to me.

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