Day 4

Subtitle: Adopting Formally-verified E2EE in a FOSS project


In this talk we take a look at Tox, a distributed/P2P and E2EE messaging solution and its FOSS implementation (toxcore). Tox utilizes state-of-the-art cryptography. However, it is vulnerable to key compromise impersonation (KCI) attacks. KCI is explained and also how this issue can be fixed by using the Noise Protocol Framework. Noise is used to design and implement E2EE messaging with formally-verified security in Tox - by utilizing libsodium. This enables more secure P2P communication with Tox and serves as enabler for Noise adoption in other projects.


Tox is a peer-to-peer (P2P) protocol that aims to provide secure messaging functionality (e.g. instant messages, audio/video calls). It is implemented in a FOSS library called “c-toxcore”. The project started in 2013 right after Edward Snowden’s disclosure of global surveillance, especially due to NSA’s PRISM program. It is intended as a distributed and end-to-end encrypted (E2EE) messaging alternative.

Tox(core) utilizes state-of-the-art cryptography. However, Tox’ authenticated key exchange (AKE) during Tox’ handshake is necessary to enable E2EE (and further security properties, e.g. forward secrecy), but is known to be vulnerable to so-called key compromise impersonation (KCI) attacks. KCI enables an (sophisticated) attacker, who compromised the static long-term private X25519 identity key of a Tox party Alice (e.g. with a trojan), to impersonate any other Tox party (with certain limitations) to Alice (i.e. reverse impersonation) and to perform Machine-in-the-Middle (MitM) attacks on Alice’s private conversations.

At rC3 in 2020 I presented the results of my master’s thesis and my proof-of-concept (PoC) implementation to fix this KCI vulnerability. Fortunately, NLnet foundation is funding the continuation of this project to realize a proper production-ready implementation. The Noise Protocol Framework from Trevor Perrin (presented at 34C3; co-author of Signal) is used to design and implement a new KCI-resistant Tox handshake - with formally-verified security properties (incl. forward secrecy, KCI resistance, etc). The Noise protocol used in Tox is Noise_IK_25519_XChaChaPoly_SHA512. NoiseIK is implemented directly in c-toxcore using only libsodium, instead of relying on a third-party library as an additional dependency (e.g. Noise-C) and therefore preserve maintainability of c-toxcore. Additionally this reduces the number of possibly vulnerable source lines of code.

This talk/session explains

  • Tox in general and its ecosystem
  • what KCI is and how it can possibly be exploited in Tox
  • how one can design and implement their own secure/E2EE communications using the Noise framework

Further it discusses the Noise implementation in Tox with regard to:

  • NoiseIK handshake: Adding the Noise_IK_25519_XChaChaPoly_SHA512 protocol to c-toxcore by using libsodium and taking inspiration from WireGuard®’s NoiseIK implementation
  • Using XChaCha20-Poly1305 for symmetric encryption (AEAD) with extended/random nonces instead of XSalsa20 or ChaCha20
  • Why and how backwards compatibility to non-Noise handshakes is implemented

This will (hopefully) enable others to adopt the Noise framework also for their implementations and projects.

This session (possibly) further includes a short demonstration and a presentation of possible future improvements.

Terminology in context of Tox:

  • Tox is the name of the protocol in general -> https://toktok.ltd/spec.html
  • The implementation of Tox is toxcore - a network library
  • The clients (using toxcore) have specific names (e.g. Toxic https://github.com/JFreegman/toxic, TRIfA https://github.com/zoff99/ToxAndroidRefImpl/)


  • https://tox.chat/
  • https://github.com/TokTok/c-toxcore/"
  • https://github.com/TokTok/c-toxcore/issues/426/
  • https://github.com/TokTok/c-toxcore/pull/2450
  • https://blog.tox.chat/2023/03/redesign-of-toxs-cryptographic-handshake/
  • https://noiseprotocol.org/