8 ms·

Tox Handshake Vulnerable to KCI

• tptacek 10y ago
  In addition to being a really succinct and well-written summary of how KCI attacks work and a good motivator for reading on modern AKE constructions like SIGMA work, this is also kind of the best possible Github bug report; in particular, I'm stealing this: Is this an accurate representation of the handshake? If so, keep reading. If not, you may safely stop reading here, close the issue, and accept my apologies for the misunderstanding.
  • CiPHPerCoder 10y ago
    Jason's report was excellent and the discussion contributed by azet and lvh was also very on-point. In contrast, some of the Tox team's response makes me want to take up drinking. The "crypto secret club gimmick" remark in particular.
    • iphy 10y ago
      Note that kebolio is in no way affiliated with Tox or TokTok, just a random person contributing to the discussion. I take full responsibility for everything I said, but I hope I don't need to take responsibility for other people's posts. As nbraud (who is in fact a contributor) noted, this has nothing to do with a secret club. I like to think that all actual contributors are open for discussion and willing to learn what they do not yet know.
      • CiPHPerCoder 10y ago
        > I take full responsibility for everything I said, but I hope I don't need to take responsibility for other people's posts. I would never ask you to do so! Thanks for clarifying.
    • kebolio 10y ago
      I'm not part of the Tox/Toktok project.
• eeZah7Ux 10y ago
  "I found this source code confusingly written (and downright scary at times) and the specification woefully underspecified and inexplicit" People, please stay away from Tox.
  • Jiig 10y ago
    I would say stay away from any 4chan pet projects.
    • kebolio 10y ago
      I would say try not to be prejudiced. Making good software and posting on imageboards aren't mutually exclusive.
      • joecool1029 10y ago
        True, 4chan does work on mobile better than HN or Reddit. Gotta hand it to them.
  • snvzz 10y ago
    > People, please stay away from Tox. By actually following the thread, I got the opposite idea. Its current active developers are well aware of Tox's flaws, do actually know what they're doing, and have a plan. They're being addressed. This is a much better attitude than seen elsewhere (such as in Telegram). And, in the first place, this is being overblown. As GrayHatter succintly puts it: > For anyone reading this, without a crypto background. The assertions being made are the same as saying: the lock on your house is broken because if someone steals your keys they can unlock your door.
    • aseipp 10y ago
      Given that the description you quote isn't what KCI is at all, I'm not exactly sure what to think of your suggestion? This is all right in the GH issue. KCI doesn't allow you to impersonate A, if you steal A's long term static keys. I mean, if you do that, you can, that much is obvious. But that's not what KCI is. It allows you to impersonate anyone else to A, if you steal A's keys and they cannot tell you are a lying impersonator. It works the other way around.
• zitterbewegung 10y ago
  A lot of these supposed "secure messaging" applications seem to roll their own crypto systems and hope that is secure. And then there users seem to promote the insecure protocol. I think we need to make a new word for this like cryptohipster .
• SlySherZ 10y ago
  Me and a friend of mine are discussing what the actual vulnerability is. What I got from the report was that you can impersonate anyone when talking to A if you have A's key. He says that is impossible and you need B's key to impersonate B when talking to A. Could anyone that knows more about this than I do step in to clarify? Thanks!
  • aseipp 10y ago
    The trick is this: in a traditional DH based key exchange, you need A) your private key and B) the other person's public key. Let's say your keypair is a/A and my key is b/B (the lowercase identifier is the private key, the uppercase one is the public key). To do an exchange, you send me A, and I send you B. You compute the DH exchange with B and a, and I compute it with A and b. The important property of the DH function is that computing DH(B,a) is the same thing as computing DH(A,b). Now, if I steal your secret key 'a', I can do two things. One, I can obviously impersonate you. But two, I can impersonate anyone else, because I can calculate the shared secret. The reason for this is that I need your private key, but I only need the other parties public key. Let's say you try to communicate with me now and someone has stolen 'a'. They can already have my public key, B, because it is public. Thus, when the exchange happens, you send me A. The attacker knows the secret key, 'a', already. So the attacker can intercept the communication, calculate the DH exchange of 'a' (which they stole) and 'B' (my public key), and they have calculated the shared secret. It is not possible for you to tell you have exchanged with the attacker, and not me. They never need my private key, only my public key, which will come through during the handshake. So it can always be intercepted. Remember, DH(B,a) and DH(A,b) are the same, so if both sides calculate DH(B,a), that's completely legitimate. This is a very simplified view (and I haven't looked at the bug report in detail, TBQH, so the case for Tox is probably slightly different), but it explains why if your keys are stolen, anyone can be impersonated to you: because the impersonator only needs public information (public keys) from that point on to forge any exchange.
    • dom0 10y ago
      Great explanation of this sometimes overlooked detail of DH-based authentication.
• lvh 10y ago
  I'm the cryptographer (lvh on GitHub) providing some context on the issue. I'd be happy to answer any other questions here, although I think the example on the ticket demonstrates the attack pretty well. The way you generally fix this is by providing appropriate binding between long-term and short-term secret. MQV does this with some weird group-breaking, but another way to do it would be, e.g.: session_key = H(l_A*E_B + e_A*L_B) (as computed by Alice) = H(l_B*E_A + e_B*L_A) (as computer by Bob) Note: DON'T DO THIS! USE NOISE INSTEAD. This is just for insight; although this how at least one of the KCI-secure AKEs works. H is a secure hash function; l_X is X's long-term secret, e_X is X's ephemeral secret, L_X is X's long-term pubkey, E_X is X's ephemeral pubkey. This works because the attack doesn't simultaneously know e_A and l_B in this model. Off the top of my head, ISTR this is how OTR's AKE works, but don't quote me on that, it's been a while since I looked at OTR specifically. This is by no means exhaustive! There are a handful of secure AKEs like this. Another classic way to do this is by signing the handshake, but that has its own share of problems. For example, the KCI attacks on TLS worked because an certificate was being used as a static DH key.
  • runn1ng 10y ago
    I am not saying that as a defense of Tox. More as a question. Why is KCI a vulnerability? Yes, I understand that the situation is reverse from a normal crypto; but still, when your keys are stolen, you are screwed anyway, your messages can be forged, it can lead to MITM, ... How is that fundamentally so different from KCI. When someone steals your keys, security doesn't apply anymore; how can a threat model include "but what if someone steals the private keys".
    • lvh 10y ago
      "Screwed" is not a binary thing. Key compromise is not an unrealistic scenario, here are a lot of things that can happen as a consequence. How bad the consequences are matters. Let me illustrate by examples: Instead of KCI, consider forward secrecy. As long as the secret key is maintained forever, you don't care about forward secrecy. However, we generally agree that forward secrecy is a desirable property. If key compromise doesn't matter, why does Tox bother to get forward secrecy? Because the outcome of key compromise matters. Instead of GCM, consider with something like CBC+HMAC-SHA256 and GCM-SIV or HS1. All take some added data per encryption in addition to a key: either a nonce or an IV. In the case of GCM, a nonce being reused is catastrophic failure: trivial forgeries and quite probably ciphertext decryption. With the other ciphersuites, there is some other failure, but nowhere near as bad. Yes, you shouldn't have repeated the nonce, but the problem is that that happens, and the question is how screwed you are when it does. Why do we care about NMR crypto? Because the outcome of nonce reuse matters. KCI is just another example. Yes, it only matters when something has gone wrong. But there is a functional difference between "the attacker gets to impersonate me" and "the attacker can pretend to be anyone to me" (KCI), just like there's a difference between "the attacker can impersonate me" and "the attacker can decrypt all communications, past and present" (PFS). Just like PFS, not having KCI-resistance as a property is a choice. There is no downside to having it. So, it is as much of a vuln as not having PFS would be.
• kevin_b_er 10y ago
  From the FAQ: "No, really, what's Tox? It's a VERY secure Instant Messenger ...." So they acknowledged this is not true in their issue tracker, but not publicly? Further, they internally claim they don't know what threats it faces, don't understand what those threats are, and don't want to worry at this time about what insecurity they have? Also: "a largely undocumented, untested, and not well-understood code base of about 19 ksloc (C)" from one of their own developers. This is quite disappointing.
  • lightedman 10y ago
    You'll find that most 'secure' projects rely upon external marketing while their internal tracking says otherwise. Man can make it, man can break it.
    • iphy 10y ago
      I don't believe that marketing like that is the right thing to do. I want to help people be more secure, not just feel more secure through some snake oil security software. Because of that, we (in TokTok) have so far avoided any marketing, and are purely focussed on making the Tox protocol we inherited from the now mostly dormant Tox project properly secure.
  • iphy 10y ago
    Some background: TokTok was started a year ago and inherited the core code from Tox with the intention to take the project to the place it claims to be in. TokTok is not equal to Tox, and we have no control over what the Tox project presents on its website. I do think that making such claims without any backing security proofs is quite bold. In TokTok, we've avoided that and instead say: our aim is to bring security software to everyone. We don't claim that the software is already secure, but we have confidence in the general architecture and are working towards provable security. Part of that is a formal specification (not the human language spec) helping us provide users and cryptographers with a security proof. We are aware of some flaws, and have concrete plans (roadmap) to fix them. I know that saying things like that statement you quoted doesn't improve confidence, but I think that saying "we're very secure" without proof is simply a lie. Many projects out there, some similar to Tox, claim security but aren't actually proven secure. We are now simply a group of people who believe in the idea and want to make it reality. I am affiliated with TokTok, not with Tox. Regarding public acknowledgement: I will update the TokTok website shortly.
• doctorfoo 10y ago
  As a Tox user, I'd love to see some of these cryptographers calling it out actually contribute lines of code. Tox fills a niche. It might not be perfectly secure, but there is also far more to software than the crypto. UI stuff takes a lot of grunt work. Please, improve this. As a user I want Tox to be secure. But also, as a user, I'll use it rather than Skype even if it does have some concerns. It's a genuine, open source, Skype replacement that more-or-less works. The encryption stuff is just the icing on the cake. It would be a great project even with zero encryption. /ramblerant
  • lvh 10y ago
    Specific recommendations for a different protocol that does not have this concern were made, and a detailed bug report with repeated explanations of the issue were provided. Why is the onus on me to also go fix the problem, when it's repeated in the issue that the authors are mostly interested in stabilizing the codebase first? (That is not a criticism, but rather: not only do I not feel this is my responsibility, the way I read it, the maintainers don't want that contribution right now.)
    • grayhatter 10y ago
      No, every Toxcore and Tox client welcome any contributions of any kind. Toktok especially. The sentiment I think we were going for is that we don't have the time when we're already working on the road map we started with. I think it's a recurring comment (If you know the problem, why don't you fix it), because it's really easy to drive by, shit all over someone's project (that they've put a lot of time into) then move on, leaving everyone who still cares about the project to feel shitty. This is in to way directed at you. You've been nothing but helpful, supportive, and understanding! You're most certainly one of the good ones. But not everyone else got that award for today.
• EnjoyTomato 10y ago
  So if I'm understanding this correctly, this exploit is only possible if someone gets a hold of your private key? This sounds more like an academic/theoretical worry than anything that would concern the average user. Realistically, if someone has your private key, you are compromised, end of story. If damage mitigation is possible it should definitely be looked into as a matter of principle, but trying to discourage people from using Tox or even from developing it over such a tiny flaw seems like little more than hubris/concern trolling. I'm sure it would look great on your blog or resume to be able to say that you, the crypto expert, found a fatal flaw in a well-established security project that forced it to shut down. Luckily it seems the actual developers of Tox have more common sense than some of these "experts", whose standards of perfection, if ever realized, would see that we all stop using technology altogether.