Redesign of Tox’s Cryptographic Handshake

In 2017, Jason A. Donenfeld (known for WireGuard®) reported an issue in Tox’s handshake [1]. This issue is called “Key Compromise Impersonation” (KCI). I will try to explain the issue as simple as possible:

In Tox you don’t register an account (e.g. with username and password), but instead your identity is solely based on (asymmetric) cryptographic information, a so-called asymmetric key pair. Such a key pair consists of a public part (public key) and a private part (private key). The public part, as the naming suggests, is public and contained in your ToxID which you share with your contacts to be able to communicate with them via Tox. The private part, again as the name suggests, needs to stay private! If someone gets in possession of your private key, they stole your Tox identity. This could, for example, be the case if someone got physical access to your computer or successfully installed malware on your system, e.g. a so-called trojan horse, to be able to extract data from it. If this happens, you will most likely have multiple problems and your Tox identity may be just one of them. The password you enter when you create your Tox profile, e.g. when you first start qTox client, is used to encrypt your profile and also your private key on your disk. If you start qTox, you need to enter your password to decrypt your private key, to be able to communicate via Tox. Your private key is then stored unencrypted in memory (i.e. RAM) while qTox is running. This means an attacker either needs to get access to your password (steal or crack it) or to read your Tox private key from memory while your Tox chat client is running.

If someone successfully stole your Tox identity (i.e. this private key), they are you – at least in the context of Tox. So they can successfully impersonate you in Tox. Now in this case the KCI vulnerability leads to “interesting” behavior. It is clear that someone who stole your identity is able to impersonate you. But because of the KCI vulnerability, they may also be able to impersonate others to you. This means, to exploit this vulnerability in practice, someone not only needs to successfully steal your private key, but additionally:

  • Know the ToxIDs of your Tox friends to be able to impersonate them to you.
  • Control the network connection between you and your friend. This could be the case e.g. if they are in the same (public) WiFi as you, or via the Internet – which is way harder and is most likely only possible for state actors (e.g. the NSA).
  • Implement their own version of toxcore because it’s not possible to exploit this issue with the current implementation. There is no public exploit available which can just be used.

In summary, KCI is exploitable, but with a huge effort.

Anyway, this is a real vulnerability and it should be fixed. The current Tox handshake implementation is not state-of-the-art in cryptography and it also breaks the “do not roll your own crypto” principle. As a solution, there is a framework called Noise Protocol Framework (Noise, [2]) which can be used to create a new handshake for Tox. More precisely, the application of Noise will only change a part of Tox handshake — the so-called Authenticated Key Exchange (AKE). Noise-based protocols are already in use in e.g. WhatsApp, which uses it for encrypted client-to-server communication, and WireGuard®, which uses it for establishing Virtual Private Network (VPN) connections. Noise protocols can be used to implement End-to-End Encryption (E2EE) with (perfect) forward secrecy (which is also the case with the current Tox implementation), but further adds KCI-resilience to Tox.

Tobi (goldroom on GitHub) wrote his master’s thesis (“Adopting the Noise Key Exchange in Tox“) on the KCI issue in Tox, designed a new Handshake for Tox based on NoiseIK and implemented a proof-of-concept (PoC) for this new NoiseIK-based handshake by using Noise-C [3]. This PoC has a few drawbacks, which is why it should not be used in practice (see Appendix). If you want to know more about his master’s thesis, see the update in the initial KCI GitHub issue [4].

He applied for funding at NLnet foundation and their NGI Assure fund to continue his work on Tox and to be able to implement a production-ready Noise-based handshake for toxcore. Fortunately, this application was successful [5]. NGI Assure is made possible with financial support from the European Commission’s Next Generation Internet programme (

The objective of this project is to implement a new KCI-resistant handshake based on NoiseIK in c-toxcore, which is backwards compatible to the current KCI-vulnerable handshake to enable interoperability and smooth transition. The main part of this project is to implement NoiseIK directly in c-toxcore to remove Noise-C as a dependency (as the only other dependency for c-toxcore is NaCl/libsodium) which was used in the PoC and therefore improve maintainability of c-toxcore (see Appendix).

The tasks in this project are:

  • Implementation of a Noise-based AKE for the use in Tox’s handshake in c-toxcore
    • This task is to implement and test an AKE for the Tox handshake based on a Noise protocol (most likely Noise_IK_25519_ChaChaPoly_SHA512, but it may change due to new insights in c-toxcore).
  • Implementation of a symmetric transport phase encryption based on a Noise-based AKE/handshake
    • This task includes the implementation of a symmetric transport phase encryption based on the secret key(s) generated during the Noise-based AKE during the Tox handshake and evaluation of Noise’s rekey feature.
    • Subtasks:
      • Decision of which symmetric cipher to use for the Tox transport phase encryption (e.g. ChaCha20-Poly1305 or XSalsa20-Poly1305)
      • Evaluation of Noise’s rekey feature to allow for session rekeying to reduce the volume of data encrypted under a single cipher key (cf. section 11.3 of Noise specification, revision 34). This may not be applicable to be implemented in c-toxcore (e.g. changing keys may be expensive). Also, it may not be necessary for ChaCha20 / XSalsa20. Further, it’s dependent on how the transport phase encryption will be implemented.
  • Support for the Noise-based AKE and the KCI-vulnerable AKE for backwards compatibility
    • This task includes the implementation of a mechanism to fall back to the KCI-vulnerable handshake if one of both peers uses a legacy c-toxcore version to provide backwards compatibility for the handshake transition phase (e.g. via cookie phase (request and response) of Tox’s handshake).
  • Error handling and testing, Documentation, Blog posts

The plan is to implement this new handshake until July 2023. Since it’s not a trivial task, there are still some obstacles:

  1. In Noise it is necessary to differentiate between the initiator and responder of a handshake. Due to the architecture of Tox it is possible that both peers initiate and respond to a handshake at the same time.
  2. Tox is P2P and UDP-based. Therefore packets can be received out-of-order or be lost altogether. In the Noise specification this is only considered for transport messages (cf. [6]).
    • “Note that lossy and out-of-order message delivery introduces many other concerns (including out-of-order handshake messages and denial of service risks) which are outside the scope of this document.” (cf. [6])

Both points are not ideal for a handshake based on NoiseIK (i.e. it would be way easier to implement it in a client-server model using TCP), but it should be possible to work this out.

Tobi is available in #toktok ( as tobi/ and ready for any input, questions, remarks, discussions or complaints.


The PoC shouldn’t be used in practice/in production because it should be improved in the following aspects (for details see chapter five of Tobi’s thesis [4]):

  • The PoC was implemented by using the Noise-C library [3]. Instead of using the library, NoiseIK or more specifically the Noise_IK_25519_ChaChaPoly_SHA512 protocol will be implemented directly in c-toxcore. This will remove Noise-C as a dependency for toxcore (i.e. the only other dependency is NaCl/libsodium) and therefore improve maintainability. Additionally this will reduce the number of possibly vulnerable source lines of code.
    • Notes on maintainability: Noise-C has a lot of code/functionality which is not necessary for c-toxcore. Also Noise-C is currently (?) not actively maintained. If NoiseIK is implemented directly in c-toxcore it is only necessary to maintain the c-toxcore codebase and it is not necessary to care about Noise-C.
  • The PoC implementation uses the ChaCha20-Poly1305 AEAD cipher during the AKE/handshake and XSalsa20-Poly1305 during the transport phase. In this project it should be evaluated if it’s possible to also use ChaCha20 during the transport phase to only use one cipher instead of two different ones (XSalsa20 is not supported by the Noise framework). For details see chapter four of Tobi’s thesis.
  • Further testing of NoiseIK handshake behavior and improved error handling.
  • The PoC implementation is not backwards compatible with the current KCI-vulnerable Tox handshake. In this project a mechanism should be added to enable interoperability with clients based on an old c-toxcore version.


“WireGuard” is a registered trademark of Jason A. Donenfeld.

DigitalOcean Sponsorship

We would like to thank a cloud hosting company DigitalOcean for sponsoring the Tox project as part of their program for sponsoring open source projects.

DigitalOcean has been providing us with reliable cloud server infrastructure for free since July 2015 — for over 6 years now! They have been very generous with supporting us and a pleasure to work with. Just as an example, in 2018 we asked them for a seemingly outrageous $660 in credits as a budget for that year, which they provided us without any questions asked.

Most of our infrastructure is running on DigitalOcean, including our website, wiki, blog, bootstrap node list, mailing list, some of CI/build system cache, as well as the domain — it’s using DigitalOcean as a name server.

In the past we have also hosted a package repository for Debian, Ubuntu, CentOS, Fedora and F-Droid, as well as a Jenkins instance for our CI, on DigitalOcean.

DigitalOcean has renewed our sponsorship for 2022, so we will be using their services in 2022 too.

Rest assured, Tox the protocol doesn’t depend on any central servers in order to work, so even if all of our servers were to go down, you would still be able to use Tox.

Stack-based buffer overflow vulnerability in UDP packet handling in Toxcore (CVE-2021-44847)

A stack-based buffer overflow vulnerability was discovered in Toxcore’s networking code that allows a remote attacker to crash the Toxcore process or potentially execute arbitrary code by sending a specially crafted packet. The vulnerability was assigned CVE-2021-44847 identifier.

All users of Toxcore that don’t have UDP disabled are affected. An attacker, knowing the target’s DHT public key, IP and port, can easily craft a packet exploiting the vulnerability. DHT public key, IP and port are all public information, publicly available on the DHT, so an attacker can target any and all Toxcore users by scraping this information from the DHT. This attack can also be used to target DHT bootstrap nodes, thus making new users unable to connect to the DHT network.

The vulnerability was introduced in 71260e38e8d12547b0e55916daf6cadd72f52e19 and fixed in 1b02bad36864fdfc36694e3f96d2dc6c58a891e4. It affects Toxcore versions 0.1.9 – 0.1.11, 0.2.0 – 0.2.12. Toxcore 0.2.13 has the vulnerability patched.

We urge everyone to update to Toxcore 0.2.13 as soon as possible.

If you are unable to update at the moment, you can immediately mitigate the vulnerability by disabling UDP, as this vulnerability happens only on the UDP code path. If you are using a Tox client, look for an option to disable UDP or for a TCP-only mode option. If you are using the library directly, you can disable UDP via the tox_options_set_udp_enabled() API function call.

Thanks to sudden6 for finding and fixing the vulnerability, irungentoo for writing a proof-of-concept attack, and iphy and nurupo for analyzing the vulnerability.

Technical details

The buffer being overflown is temp in the handle_request() function, located at DHT.c:365 in Toxcore 0.2.12. The overflow happens on the following line, a few stack frames inside the decrypt_data() function call, due to the 5th argument of decrypt_data() being incorrectly calculated. The 5th argument, length – CRYPTO_SIZE, incorrectly expands to length – 1 + 32 * 2 + 24, when the intention was for it to expand to length – (1 + 32 * 2 + 24). This allows decrypt_data() to write more data into temp buffer than intended, overflowing the buffer and writing past handle_request() function’s stack frame, smashing the stack.

Tox has moved to Libera Chat IRC

Due to the recent takeover of Freenode IRC[1] and Tox IRC channels being hostilely taken over by the new Freenode staff without any prior notice[2], we have moved our IRC presence to Libera Chat IRC[3]. All Tox IRC channels have moved to Libera. Any Tox channel you see on Freenode (or any other network) is not official. You can see the up-to-date list of our IRC channels on the wiki[4].

We are not the only project that has made the switch. Many high-profile projects and communities have left Freenode for Libera: Arch Linux[5], curl[6], Django[7], FFmpeg[8], Gentoo[9][10], Haskell[11], NGINX[12], PostgreSQL[13], Python[14], Ubuntu[15][16], Void Linux[17], Wikimedia[18] and many more[19]. Some of them have had their channels taken over by the new Freenode staff as well[20]. If you want to learn more about the incident, this blog post has links to many of sources[21].

Libera Chat is run by the staff that ran Freenode before it got taken over[22]. It’s the continuation of Freenode, with the the same staff, rules, IRC services and many of the same projects. Tox has been on Freenode for almost 8 years, since its very inception in June 2013, and many Tox developers had been using Freenode even before that. It saddens us to have to part with Freenode, even if just in name, and we are grateful to its former staff for managing it for us for such a long time and to Freenode’s sponsors for keeping the lights on. We hope that Libera becomes the new IRC network of choice for open source projects like Freenode once was.

See you on Libera Chat!

ToxCon 2019

ToxCon 2019 Poster

This October the Tox developer community will be holding its third annual conference at Metalab in the heart of Vienna, Austria. The event will be 3 full days, from Friday, October 11th to Sunday, October 13th.

We will talk about Tox, and other security related and interesting topics. If you would like to attend, meet the Tox devs, do some live hacking, or just socialize — get a free ticket and reserve a T-shirt. You can find the exact address on your ticket.

Want to give a talk about your project? Please apply here!

If you have any questions about booking, travel arrangements, talks, or anything related to the event, join #toxcon IRC channel on Freenode and contact robinli, strfry or zoff99.

ToxCon 2018 report

This year’s ToxCon was super fun, thanks to everyone who attended it!

If you have missed the event, list of talks, talk slides and some photos from the event are available online. No videos are available as it was decided not to record the talks.

We are planning to hold another ToxCon the next year, so keep an eye for announcements. If you are working on anything fun with Tox and want to share it with the world, consider giving a talk at the next ToxCon — we would be happy to host your talk.

Here are a couple of the photos from the event.

ToxCon2018 organizers
ToxCon2018 organizers
ToxCon2018 group photo
ToxCon2018 group photo

Memory leak bug and new Toxcore release fixing it

A memory leak bug was discovered in Toxcore that can be triggered remotely to exhaust one’s system memory, resulting in a denial of service attack. The bug is present in the TCP Server module of Toxcore and therefore it affects mostly bootstrap nodes. Regular Tox clients generally have the TCP Server functionality disabled by default, leaving them unaffected.

The bug was introduced on July 15th, 2014 in commit 22d28ddf36563e2d0018fc20cafdfe61278dd67f, making all previous versions of TokTok c-toxcore and irungentoo’s toxcore vulnerable.

The bug is fixed in TokTok c-toxcore v0.2.8. The bug is also fixed in the master branch of irungentoo’s toxcore, in commit bf69b54f64003d160d759068f4816b2d9b2e1e21. As a general reminder, if you are still using irungentoo’s toxcore, we strongly encourage you to switch to using TokTok c-toxcore instead as it’s a lot more actively developed and maintained. In fact, irungentoo’s toxcore is neither being developed nor maintained for some time now, aside from merging only the most critical fixes from TokTok c-toxcore from time to time, missing all other important fixes.

If you are using TokTok c-toxcore v0.2.8, you should be unaffected by this bug.

If you are using an older Toxcore, for example a client you use didn’t release an update, make sure that you have the TCP Server functionality disabled in the client settings and you should be unaffected. Some clients, like qTox v1.16.3 and uTox v0.16.1, don’t provide the user with an option to enable the TCP Server, having it always disabled, and other clients, like Toxic v0.8.2, do provide the TCP Server option, but it’s disabled by default. Note that it’s possible that some other clients have the TCP Server option enabled by default.

If you are running a bootstrap node, we strongly encourage you to update to TokTok c-toxcore v0.2.8 rather than disable the TCP Server option. In fact, we will be making Toxcore v0.2.8 the minimal required version for all of the nodes on our bootstrap node list. TCP relay functionality is very useful for mobile users and those behind restrictive NATs, and given that it’s mostly bootstrap nodes that act as TCP relay servers, as clients generally have that option disabled, even a few of those nodes disabling TCP Server functionality would reduce the number of TCP relay servers Tox clients can use considerably.

Update (January 2022): This vulnerability has been assigned CVE-2018-25021 identifier.

ToxCon 2018 Update

ToxCon 2018 Info

As promised, here is more information on ToxCon 2018.

Tox developer community will be holding the conference from Friday, October 12th, to Sunday, October 14th — a 3 day event, at Metalab Vienna, a hackerspace located in the heart of Vienna, Austria. We have many talks prepared for you: from the progress Tox has made in the last 12 months, to security-related and other interesting topics. The the full schedule of the event is available online and there is also an Android app that you can use to get updates if more talks get added.

If you would like to learn more about Tox, meet the developers, do some live hacking, or just socialize, then this is the event for you. The tickets are free and you have an option to buy a sponsored ticket or a ToxCon T-shirt. All money from the sponsored tickets and the T-shirt sales will go towards a dinner for the speakers, and, if there is money left, T-shirts to give away.

For questions about booking, travel arrangements, talks, or anything related to the event feel free to join the #toxcon2018 IRC channel on Freenode and contact one of the event organizers: robinli, sudden6 or zoff99.

ToxCon 2018

ToxCon 2018 Poster

In October the Tox developer community will be holding a conference in Vienna. Join us as we talk about the progress we have made during the last 12 months with Tox and other security related topics. There will be lots of talks and other cool things to see.

For more details join the #toxcon2018 IRC channel on Freenode and contact robinli, sudden6 or zoff99.

More information will be revealed in a future post.