Noted - thanks TNT_BOM_BOM
Since you originally documented it in the wiki… Do the instructions still look good? @HulaHoop
Yes everything still looks good and having it in Whonix made things much easier.
qTox is still actiely developed and their community is vibrant and holds annual cons.
Tox should not be included. It is not secure.
Also see the big red warning on the readme:
Tox was a great idea. Sadly is insecure as you say. Maybe switch default Whonix IM to something like gajim OMEMO since not everybody has a phone number to use Signal?
I also feel OMEMO need more eyes.
Its already known before even Tox integrated into whonix, You have something new to say?
If I am not mistaken, I was reading breaking Tox encryption through MITM is possible, confirmed by Tox developer.
Some say it’s experimental while it’s actually stable for legal reasons, as disclaimer. Nobody wants to provide guarantees and be liable. Others say it’s experimental, and they mean, it really is experimental. Tox is the latter case.
Since it’s supposedly an end-to-end encrypted messenger, it’s a bad choice for installation by default.
This is irrelevant to the ticket above, But this is important to be public if this is the case of the E2EE inside it, Do you have the study case or so then we can even share it on our social media.
If cant be proven against then Tox stay as best DHT texting app and better to keep it as there is no critical reason to remove.
It’s exactly what the ticket is about. Have you read it?
I think the encryption being totally broken is a critical enough reason for it to be removed.
Where? its about impersonation when private keys stolen not anyone can listen to any conversation between tox-tox like emails yes?. Check as well this ticket has good design of what can/cant tox do: (thought the info mentioned there roughly old)
Talked to their channels JFreeman said:
“As of right now the Tox security model doesn’t cover giving your private key to others. if your private key becomes compromised it’s up to you to inform all of your contacts and cease using it”
But there is work done towards it:
This is nice documentation about Tox protocol:
Concretely, the issue is that if A’s longterm static private key is stolen, an attacker can impersonate anybody to A without A realizing.
That indeed doesn’t immediately strike me as the worst encryption bug ever. “If the private key was stolen” is a pretty advanced threat model, no? Maybe I missed something. Is this usually a standard encryption feature everywhere?
- What would happen if a Tor onion v3 key was stolen, impersonated? Would Tor notice that and report that?
- One certainly had no way to notice if a gpg signing key or encryption key was stolen, unless there was evidence of unauthorized signed messages or unauthorized decrypted messages. In that case, one could publish the gpg revocation key for whatever that’s worth.
- Any other applications?
- A feature in OTR?
- A feature in OMEMO?
More impressive would be if the encryption could always be broken by an active (or even passive) MITM. Is there such a bug?
Heap overflow sounds bad.
Problems with sharing and verifying private keys is a UX problem since the dawn of E2EE and not a security problem. However code implementation bugs that allow breaking of the cipher text or remotely exploitable programming errors are grounds for removal. Please update the wiki to deprecate Tox documenting this recent info. It is popular enough to mention, though we have policy of “if it’s not listed it’s not safe”.
The ability to gain the private keys of an application/tool in user host thats enough privileges for outside attacker to do many more things than just stealing keys, and if they leaked due to user error then there is no way that the user got notified at least instantly in most cases of what you have mentioned.
Agree if this is the case here, but this is not the case here. If there is remote code exploitation or it just doesnt encrypt anything (false/weak encryption) or so then for surely this is must be labeled to be removed but the bugs we are talking about are faraway to be greefly insecure.
You’re misunderstanding this. KCI attacks are, by definition, MITM attacks. Client X communicates to client Y. Attacker Z impersonates client Y. Client X inadvertently sends confidential messages to attacker Z, believing they are client Y. Attacker Z then relays the messages back and forth to / from client Y so there is no indication of compromise.
This a nice overview of such an attack on an old TLS version:
The same can be done with Tox.
Also, this is most certainly not going to be the only issue of Tox. The author of that Github ticket was not even doing a thorough analysis. This vulnerability is low hanging fruit.
I found this source code confusingly written (and downright scary at times) and the specification woefully underspecified and inexplicit
But on the off-chance that 5 minutes of source code review at 4am yielded something accurate
Thats our whole discussion above , which Z need to know Y private keys, similarly to the TLS attack even mentioned in the link you provided:
Controlling a Client Certficate
Various options for an attacker to control the private key of a client certificate installed at a client device exists and are conceivable. One very natural way that comes to mind would be to employ social engineering technique
So if your private keys leaked its game over not just for Tox but many other tools as well.
Agree, This actually what is annoying about Tox which is its not new protocol been like 7 years but until now not yet audited. Hope they do that soon.
You’re still misunderstanding the threat model of this. If an attacker manages to get the private key of client X, then they can impersonate client Y despite client Y’s private key never being leaked. This is possible due to Tox’s insane key combination. In orthodox encryption schemes, if the private key of X was leaked, then the attacker would only be able to impersonate X, not Y. Tox allows the entire communication to be compromised by one key being leaked rather than the two that is usually necessary.
This is not a particularly advanced threat model. Data gets leaked and the impact of said leak must be contained. Perfect forward secrecy also has a similar rationale for example.