"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.
People, please stay away from Tox.
"We have a largely undocumented, untested, and not well-understood code base of about 19 ksloc (C)."
Oh lord. Then another zinger from the same author:
"Tox provides some strong security guarantees. We haven't got to the point where we can enumerate them properly, given the general lack of understanding of the code and specification."
Stay away!
I am working on Tox because the basic architecture is sound, even though there are some easy to fix security issues. I've started on a well-documented rewrite, but I had to put that on hold to make time for toxcore itself. Zetok has been working on a rust rewrite. I have good hopes for that project and I support it in any way I can.
We are actively working on making the 19k lines of C code better tested, better understood, and better documented. This takes time, but we're focussing on it and I believe we are making good progress.
Again, I can understand that such a statement incites fear, but saying anything else would be a lie. We're working on it.
If your intention is the same as mine (https://github.com/TokTok/website/blob/master/toktok/mission...), then I would hope we can work together in some way. Whether that means helping with discovery of security flaws, by helping us clarify sections of the spec (at this point we can't really call it a spec yet, it's more of a brain dump of the original author), or any other way, I'm happy to discuss opportunities.
If your intention is to incite rage and hatred, our discussion is over. I hope we can do the former.
EDIT: This last sentence is not intended to point at anyone in particular. It's more of a general "you". I'm thankful to zx2c4 for starting the discussion.
Thanks for the honesty. It's very much appreciated. I'd hate for somebody to somehow miss critical facts like these, and make a dangerous decision for themselves.
> If your intention is to incite rage and hatred
What a mystifying insinuation, especially toward somebody who actually took the time to try and write a clear explanation of the vulnerability and what KCI is and how resistance to it is an expectation of any modern AKE, etc. Such subtle jabs and hostility toward well-intentioned bug reporters doesn't inspire much faith.
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.
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.
If A got his keys stolen, he's indeed in for some trouble.
This is slippery-slope weasel-wording. The particular impersonation-to-A scenario is well known (due to a standard DH key agreement property) and can be protected against (see lvh's top comment for examples how it's possible to do that).
Please.
> The particular impersonation-to-A scenario is well known (due to a standard DH key agreement property) and can be protected against (see lvh's top comment for examples how it's possible to do that).
Yes, it's an excellent explanation. But ultimately, while this should be fixed, it is not critical, as it requires A's private keys be stolen.
For the layman, without touching into the crypto details, the analogy GreyHatter made is not so bad.
(I've made the same point in more detail here: https://news.ycombinator.com/item?id=13395294)
No, I wouldn't. I've only seen this reply after reading the post you're referencing, which I found quite elucidating.
I would, however, note there's a huge difference in consequences. Without forward secrecy, old communications would be compromised when the private key is. This isn't comparable to anything about future conversations after the key is stolen, a situation where I'd personally have way lower security expectations and would be surprised if this wasn't the case among the general public, outside the crypto community.
In the first place, short of another HeartBleed-style vulnerability (not impossible, as heartbleed demonstrated), the key being stolen would typically involve a serious compromise of an endpoint, where the attacker achieves enough execution to install a rootkit, at which stage, with KCI or without, the attacker can present to the compromised user whatever they want.
I do, to some degree, understand the attitude of the current developers behind the toktok toxcore fork. They want to read and understand the code, then produce documentation about the code and the protocol, and only at that point (with all the information available) tackle the design issues, including this arguably low priority KCI issue. I believe it reasonable, particularly after considering that they're spending about zero effort in promoting its use to the general public.
While it's pretty fair and I'm sure welcomed for their code to be looked at and vulnerabilities found, all things considered, I do not think it's, at all, fair to give them and their early-stages project the kind of negative spotlight they're getting.
The specific claim about future communications is having people impersonate anyone to _you_, not you to anyone. I don't think this is obvious to the general public. More importantly, this implies that the victim knows their key has been compromised.
My point was that I don't think it's obvious to the general public, either, that they can have any expectation after their key is compromised. Forward secrecy, some of them might have even heard about, particularly in the present climate where ssllabs is requiring it for its A grade.
> More importantly, this implies that the victim knows their key has been compromised.
I threw in some talk about my and the general public's expectations about the scenario where an endpoint's key is compromised, but I don't think I included knowing it actually happened among these expectations. The rootkit scenario which I expect as most common compromise (endpoint machine utterly compromised) kind of implied the user is none the wiser.
I'm not sure there's anyone out there that expects an Amiga guru meditation style alert saying "Your private key has been compromised!" to appear.
> The vast majority of key compromises are operational screwups with data disclosure, they generally do not lead to arbitrary code execution.
This is honestly surprising.
https://github.com/TokTok/c-toxcore/issues/426#issuecomment-...
What's part am I missing that if we used hash(long_key pair + emp_key pair) protects us if the long term is known by an attacker? Why couldn't the attacker intercept the emp_keys.
I'm assuming there's no key signing done here.