[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [CONTRIBUTE] [DONATE]

Possible TOR backdoor

Support
#1

The whonixTM wiki currently assumes that aside of known network attacks based on TOR and operational security fails of their users that TOR would hold against all kind of attacks except targeted (network) attacks and malicious relays. one thing that is not documented is security of TOR source code and their encryption choices.

in this thread I will discuss in detail a possible TOR backdoor in current TOR agent (and TOR Rust rewrite) that makes all TOR traffic same as unencrypted HTTP traffic.

before I start I recommend you read about ECDSA and it’s proven backdoor
while there are projects like SafeCurves they all focused on implementing simpler and less secure implementation in order to merely hopefully reduce chance of backdoor working, this approach wouldn’t work due fact they still use same bugged algorithm.

For longest time I thought TOR used RSA but as turns out it has been using ECDSA for quite a while now. I tried contacting TOR developers to see why they chose it over RSA but to no avail.
so I consulted wiki and ECDSA apparently has a small improvement of speed when signing but RSA is still faster while encrypting which again most operations in TOR code are encrypting and not signing

And to add more nails to coffin both ECDSA and RSA fail when it comes to quantum computers, however, RSA is proven to be much more secure against traditional computers than ECDSA is.
ECDSA is also a lot more complex algorithm wise which opens up for more backdoors and attacks in implementations aside from the main backdoor

It doesn’t make sense why they would insert a bugged algorithm in a software that is used by a lot of important and vulnerable people
TOR developers are not amateurs they have chosen ECDSA for a reason despite it’s proven backdoor

Someone like NSA who also been proven to spy on cables in sea would be able to capture TOR traffic and decipher them without running a single relay

I am not sure how this flew under the radar. I am not sure what whonixTM could do about this except the very laborious switching to another network. This is merely a discussion and not fear mongering post

#2

As for claims / evidence / proof that Tor crypto is insecure or even has a backdoor, I would suggest convincing an cryptography expert of that claim to lend it authority / credibility.

A number of related places come to mind…

Is any more explicit mention required?

2 Likes
#3

The claims you posted doesnt represent the references you used, ECDSA is NOT backdoored according to wikipedia, its just effecting:

which also say:

“NSA paid RSA Security $10 million in a secret deal to use Dual_EC_DRBG as the default in the RSA BSAFE cryptography library, which resulted in RSA Security becoming the most important distributor of the insecure algorithm”

so what you are suggesting is just worst alternative.

Related good places to read:

https://cseweb.ucsd.edu/~nadiah/

#4

you are confusing RSA the algorthim with a company that has nothing to do with RSA algorthim, company actions does not mean RSA is backdoored, RSA is NOT backdoored and ECDSA is defientely backdoored, the random number generator is just 1 simple piece of the complex ECDSA algorthim and likely has even more backdoors somewhere in the complex specifications while in RSA its easier to verify claim to simplicity when compared to ECDSA.

there’s also a bunch of other things why RSA is better but you left them all to go after a mere claim while ignoring proven allegations

one thing stands, neither of them are good enough at rate of tech evolving and post quantum alternatives are needed

#5

Same.

If the choice between RSA and ECDHA i would choose ecdha no question about it, ecdha p384 is equivalent to 7680 bits (“security strength” of 192, e.g. AES-192) [Ref page 67-68], and faster than RSA.

Agree with this one, but no current alternatives in TLS yet, and TorProject aware about post quantum crypto but also its up to them when do they see it mature to be used in Tor.

Also nor I2P implementing this feature (not anytime soon either), so unless something proven practically harmful i believe nothing going to change at the moment in these projects.

#6

AES 192-256 are quantum proof with reasonable security while curves are not. please don’t compare symmetric and asymmetric encryption again because former wins every time faster, smaller and more secure

I2P developers are anonymous you can’t tell if they will implement something or not and they use El-Gamal encryption which is basically RSA

#7

I2P developers are anonymous you can’t tell if they will implement
something or not and they use El-Gamal encryption which is basically RSA

Not entirely true, firstly I2P (java) current developers are not
anonymous whether zzz or eyedeekay or eche|on or str4d none of them
anonymous (the only core developer which disappeared in 2006~ was
anonymous jrandom).

secondly El-Gamal yes it was used but not on the roadmap anymore,
current I2P tunnels can use only ECIES-X25519 or both, but not going to
be kept like this for the future check e.g:

https://geti2p.net/spec/proposals/156-ecies-routers

#8

related wiki chapter:

I don’t see how developer anonymity vs pseudonymity vs real name use makes any difference in this context. It’s not like developers of some project are anonymous and not communicating about their plans with anyone. Maybe there are such projects but it seems to me it is quite possible to ask questions to I2P and seems like at least lots of them are also answerd.

#9

Tor uses DJB’s ECC and not the NIST curves which are messier to use and implement.

Tor uses a limited subset of the OpenSSL crypto lib.

So the assumptions and therefore conclusions made in the OP’s post are wrong.

All aforementioned projects are FLOSS so discovery of any malice should be easy by knowledgeable academic experts (which we are not).

#10

“…that makes all TOR traffic same as unencrypted HTTP traffic.”

In this context, perhaps the following is worth mentioning.

I and some other users have noticed since the latest update of the TorBrowser and the associated permanent activation of the “Only https mode” that in certain random situations the warning is issued that no “https version” of the corresponding page exists, although this is demonstrably not true. It also asks if you want to view the page in http mode.
Since http is still rarely used today and the messages are increasing, it is to be considered:

This could be a bug. But it could also be that this is intended to tempt users to actually call up a page without https and thus become more “transparent”.

This is supported by the fact that the warning message disappears in almost all cases after changing the circuit.

#11

FWIW I’m going to make more time for the Whonix forum in the future. Re: I2P - ElGamal will be entirely phased out when SSU2 is complete. It will be available optionally for the forseeable future as a backward-compatibility feature for dual-keyed I2P services(ElGamal+ECIES-X25519) but won’t be used for anything by default. We are just beginning our first discussions of post-quantum I2P.

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]