Opened 6 years ago
Last modified 10 months ago
#11093 new defect
obfsproxy should use C implementation of UniformDH
Reported by: | asn | Owned by: | |
---|---|---|---|
Priority: | Medium | Milestone: | |
Component: | Archived/Obfsproxy | Version: | |
Severity: | Normal | Keywords: | |
Cc: | Actual Points: | ||
Parent ID: | Points: | ||
Reviewer: | Sponsor: |
Description
We are currently using a C implementation of UniformDH that is quite slow (even with gmpy2 for mod exp).
Yawning implemented UniformDH in C using OpenSSL and we should use his library.
He posted an obfsproxy patch in #11015 :
https://trac.torproject.org/projects/tor/attachment/ticket/11015/0001-Add-support-for-using-py-uniformdh.patch
And the implementation can be found in:
https://github.com/Yawning/py-uniformdh
Child Tickets
Change History (4)
comment:1 Changed 6 years ago by
comment:2 Changed 2 years ago by
Severity: | → Normal |
---|
Set all open tickets without a severity to "Normal"
comment:3 Changed 11 months ago by
Owner: | asn deleted |
---|---|
Status: | new → assigned |
asn does not need to own any obfuscation tickets any more. Default owners are trouble.
comment:4 Changed 10 months ago by
Status: | assigned → new |
---|
tickets are unassigned, reverting to 'new'
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.