Adopting the Noise Key Exchange in Tox

Tox [0] is a free and open source peer-to-peer instant messaging protocol and implementation, that aims to provide secure messaging. It’s intended as an end-to-end encrypted (E2EE) and distributed Skype replacement. Tox’ cryptography is based on the NaCl library from Daniel J. Bernstein [1]. The cryptographic primitives for the key exchange (X25519), authentication (Poly1305) and symmetric encryption (XSalsa20) are state of the art peer-reviewed algorithms.

Unfortunately Tox’ authenticated key exchange (AKE) during Tox’ cryptographic handshake is a "home-brewed" cryptographic protocol (remember: do not roll your own crypto!) and is known to be vulnerable to key compromise impersonation (KCI) attacks [2]. In this talk we will show why this vulnerability is challenging to exploit in practice. However, we will also present a fix to this vulnerability by designing and implementing a new cryptographic Tox handshake with formally-verified security properties.

KCI is a vulnerability of AKE protocols, which in this case could enable an attacker, who compromised the static long-term private X25519 [3] key of a Tox user Alice, to impersonate any other Tox user (with certain assumptions) to Alice ("reverse impersonation"). Furthermore, this would enable this attacker to perform a Man-in-the-Middle (MitM) attack and therefore tampering of exchanged messages. X25519 key pairs, that are necessary for the distributed hash table (DHT), make an actual KCI-attack more complex as suggested in the initial vulnerability report by Jason A. Donenfeld.

The Noise Protocol Framework [4] from Trevor Perrin (co-author of Signal [5]) was used to design a new KCI-resistant Tox’ handshake. The Noise Protocol Framework is intended to use by protocol designers to create secure channel protocols based on Diffie-Hellman (DH) key agreement. Noise provides different handshake patterns for different use cases. These patterns define a sequence of DH operations to calculate a shared symmetric session key. The security properties of these patterns are formally verified. These security properties can include forward secrecy, identity hiding and most notably KCI-resistance. A handshake pattern is instantiated by DH functions, cipher functions and hash functions to give a concrete Noise protocol. Such Noise protocols are already used in some applications, like WireGuard VPN [6]. The Noise protocol used in Tox is Noise_IK_25519_ChaChaPoly_SHA512.

The Noise-C library from Rhys Weatherley [7] was used to implement the new AKE in c-toxcore [8]. The implementation is currently in proof-of-concept state and will be further improved. In future work, instead of using the Noise-C library, which supports most of Noise’ handshake patterns and all cryptographic primitives, only the Noise protocol used in the Tox handshake will be implemented in c-toxcore. This will remove Noise-C as a dependency (i.e the only other dependency is NaCl/libsodium), reduce source lines of code and therefore reduce the attack surface. Noise also provides functions to further improve security, like session re-keying, which could also be adopted in Tox.

Terminology in context of Tox:

• Tox is the name of the protocol in general
• The implementation of Tox is toxcore - a network library (see [8])
• The clients (using toxcore) have specific names (e.g. qTox [9])

• Full Master Thesis: https://pub.fh-campuswien.ac.at/obvfcwhsacc/content/titleinfo/5430137
• [0] https://tox.chat/
• [1] https://nacl.cr.yp.to/
• [2] https://github.com/TokTok/c-toxcore/issues/426
• [3] https://ed25519.cr.yp.to/
• [4] https://noiseprotocol.org/
• [5] https://signal.org/docs/
• [6] https://www.wireguard.com/
• [7] https://rweather.github.io/noise-c/index.html
• [8] https://github.com/TokTok/c-toxcore
• [9] https://github.com/qTox/qTox