![]() So they can successfully impersonate you in Tox. this private key), they are you – at least in the context of Tox. If someone successfully stole your Tox identity (i.e. 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. Your private key is then stored unencrypted in memory (i.e. If you start qTox, you need to enter your password to decrypt your private key, to be able to communicate via Tox. when you first start qTox client, is used to encrypt your profile and also your private key on your disk. The password you enter when you create your Tox profile, e.g. If this happens, you will most likely have multiple problems and your Tox identity may be just one of them. a so-called trojan horse, to be able to extract data from it. This could, for example, be the case if someone got physical access to your computer or successfully installed malware on your system, e.g. 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. 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. Such a key pair consists of a public part (public key) and a private part (private key). with username and password), but instead your identity is solely based on (asymmetric) cryptographic information, a so-called asymmetric key pair. In Tox you don’t register an account (e.g. I will try to explain the issue as simple as possible: This issue is called “Key Compromise Impersonation” (KCI). Donenfeld (known for WireGuard®) reported an issue in Tox’s handshake. A vulnerability was discovered in Toxcore that allows one to learn the IP of a target user by only knowing their Tox Id and without being friends with the target user.In 2017, Jason A. The Tox protocol is designed in such a way that only friends (contacts) which you have accepted friend requests of are able to learn your IP based on your Tox Id and no one else. Thus, being able to learn the IP of an owner of a Tox Id without them accepting a friend request is an undesired behavior. This is a vulnerability in an implementation of the Tox protocol, a vulnerability in the Toxcore library, not in the Tox protocol itself. The vulnerability affects both TokTok’s c-toxcore and irungentoo’s toxcore. The vulnerability affects only UDP mode of operation. TCP-only mode is not affected by the vulnerability. TokTok’s c-toxcore has patched the vulnerability in version 0.2.2. irungentoo’s toxcore doesn’t have the vulnerability patched as of this moment and it’s unknown if it ever will, as it hasn’t been actively maintained for years. irungentoo’s toxcore was patched after this post was written. The vulnerability was privately reported to us by Evgeny Kurnevsky on April 14th and publicly disclosed with our permission on April 15th, along with a patch fixing the vulnerability, made by Evgeny Kurnevsky. The vulnerability was found when Evgeny was working on tox-rs project – a Tox implementation in Rust. ![]() We urge everyone to update to the latest TokTok c-toxcore as soon as possible. You can immediately mitigate the vulnerability for yourself by using TCP-only mode.ĭue to the nature of the vulnerability, using Toxcore in which the vulnerability is patched is not enough to protect yourself. The way the patch works is that it can’t protect you from the vulnerability but it can and does protect other peers. So in order to be protected from the vulnerability, everyone should switch to using the patched Toxcore. The more people use the patched Toxcore, the less is the chance to be vulnerable. Note that this applies only to the UDP mode. ![]() If you use the TCP-only mode, you are fully protected as you are not affected by the vulnerability. Here are the technical details of the vulnerability. The vulnerability is caused by the Onion module of Toxcore erroneously allowing to onion-route any data, any Tox packets, without a restriction. By the Tox protocol specification, when Alice makes an onion-routed request to Bob and then Bob sends an onion-routed response back to Alice, the payload of the onion-routed response sent by Bob arrives to Alice as it is, stripped of any identification that it was ever onion-routed by the last onion hop, and is interpreted as a regular Tox packet by Alice. Alice has no way to distinguish onion and non-onion packets - she has no idea if the packet originated from the node it received the packet from, or if the packet was relayed on someone else’s behalf as part of an onion-routing.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |