I’d love to see any credible explanation as to how this could have happened by accident.
He found a flaw, they fixed it. The flaw itself is of a kind common to a home-brewed crypto and it was lying on a surface. Saying that Telegram made this mistake on purpose is, if you pardon my French, making shit up.
Yes, they fixed it.
No, you can’t accidentally write code that pulls DH nonces from your server.
>The flaw itself is of a kind common to a home-brewed crypto
You can’t say things like this and then proceed to accuse others of making up shit.
Telegram doesn't have reproducible builds, do they? So if they really wanted to fuck people over, all they had to do is to ship a build that uses predictable PRNG. The vast majority of users will use vendor-supplied binaries, so chances are that for any pair of peers you will be able to fully recover all their secrets and eavesdrop on the traffic. You don't even have to be Telegram to do that. In fact, this works against any protocol... unless client binaries are routinely audited and matched against their source, which is never the case with any of the clients. The only example I am aware of was Zimmerman's PGPfone back in mid-90s.
So, yes, I think that you are seeing things that are not there and it's yet another case of stupidity rather than malice on part of Telegram's devs.
This doesn't really matter that much, the source code isn't very helpful while auditing a RNG.
Most of the time Telegram doesn't even encrypt conversations, yet this is their main selling point.
>So, yes, I think that you are seeing things that are not there and it's yet another case of stupidity rather than malice on part of Telegram's devs.
No. I just don't think it matters whether this was stupidity or malice, sufficiently advanced stupidity is indistinguishable from malice. This was not your typical crypto fail. You suggested that this is a common kind of error, can you point at someone else that did this?
I think it's fair to assume malice in the case of Telegram, their "secure encrypted messaging" application still doesn't even encrypt most conversations.
Regarding the nonce attack, it looks like the devs responded and said it was because of poor random numbers source on the client, which I personally don't understand as a justification. However, they said they'll remove it in the next update and that nonce has been "0" up until now.
Regardless, all of these messengers for cell phones aren't great if you are paranoid. That's because the hosting company's servers have all kinds of data on you as it is. Your contacts, access to SMS, access to location, camera, mic, photos, and all the files on the device.
This is true for all the messengers that are currently in widespread use.
If you are paranoid, use Pidgin with OTR plugin.
Don't do that, this is a super bad idea. If you really have to go that way, at least use coyim or something. Definitely not anything libpurple based.
On the CoyIM site it says: "Not yet audited. Do not use for anything sensitive."
>Because they had a code exec vuln in 2017?
No. Look at the code, it’s scary! Pidgin and libPurple were not built with security in mind.
Coyim is being built ground up in an effort to avoid the numerous issues surrounding Pidgin/libOTR.
I think you absolutely should not use either, but if you’re going to use one at least use Coyim.
A messenger that really cares about privacy would never require user to provide a phone number and would not keep decrypted messages on the server.