Tox / qTox - Whonix Integration

update , qtox is possible to be installed from debian repos starting from next debian code buster:

cc @HulaHoop @Patrick

also @0brand & @torjunkie might update the installation of tox/qtox in our wiki.

2 Likes

Please create a Whonix 15 ticket.

1 Like

done:

https://phabricator.whonix.org/T889

1 Like

Noted - thanks @nurmagoz

1 Like
2 Likes

Some changes Template:Tox: Difference between revisions - Whonix


Since you originally documented it in the wiki… Do the instructions still look good? @HulaHoop

1 Like

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.

2 Likes

Tox should not be included. It is not secure.

Also see the big red warning on the readme:

1 Like

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.

1 Like

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.

1 Like

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:

Quote Tox Handshake Vulnerable to KCI · Issue #426 · TokTok/c-toxcore · GitHub

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

1 Like