[tptacek]

I'm worried that to people unfamiliar with modern crypto, the diagram of your protocol and the "technical FAQ" might sound credible or even convincing. But it is not.

The message integrity protection this system describes is not up to modern standards. The system seems to use SHA1, which is a fault for a new system (no new system should use SHA1), but that's not the biggest problem; the biggest problem is that the SHA1 digest of a message is not an authenticator of that message, because an attacker can generate the same digest given only the contents of the message. Your FAQ makes a claim that is simply false when it says that the SHA1 of a message is a MAC. It simply is not. Moreover, the process of using a secure hash to generate a MAC isn't simple. HMAC-SHA1 and SHA1 are not comparable functions; HMAC-SHA1 goes through a series of elaborate steps to remediate vulnerabilities that come from trying to use SHA1 directly.

AES-IGE is an anachronism. Candidly: most of the Internet crypto practitioners who looked at this system learned about IGE for the first time because you decided to use it. IGE is a block cipher mode that was designed in 1977 and forgotten about in 1978. It's so archaic that academic cryptographers joke about how many times it has been reinvented and then rebroken. The last time your cryptosystem was discussed on HN, I provided a link to a thread in which Jutla laid out a simple, devastating attack on the mode in ASCII text in a mailing list post. You didn't respond.

Your use of RSA seems naive and ineffective. Your system "resists" MITM attacks by "allowing" clients to trust servers you operate. No other modern secure messaging protocol has this characteristic. Every OTR user in the world runs software that was designed not to trust central servers. Not only that, but the technical attributes of your RSA usage appear incompetent. RSA padding is not optional; Nate Lawson has argued for years that RSA "padding" should be renamed "armoring" for exactly this reason: because developers like those on your team assume that it is a minor detail. It is not. 80% of the RSA implementations on the Internet are insecure because they use the default padding (PCKS1v1.5) which was carefully designed (in the 90s) to resist attacks, but missed some. You use ad-hoc padding.

I don't understand why any professional in the world would spend any time on your contest. Moxie Marlinspike's response to that contest was devastating: he laid out a comically broken messaging protocol, one no professional would ever knowingly use, and showed that your contest rules would make that broken system survivable. Your contest appears to be a cynical attempt to prey on the misconceptions of uninformed users.

You have deliberately chosen the NSA as your adversary in your promotional content. You have deliberately chosen to give yourself no margin of error in designing this system. You've deliberately chosen a problem domain that requires profound trust in your team. You are not living up to the constraints you've set for yourself. I fear that the damage you've done to your project may be unrecoverable.

[kbenson]

Okay, here's an authority I can get behind on this debate, not being familiar enough myself to parse most of the criticisms for their veracity. I don't always agree with your political or economic take on a subject, but I've never seen anything but excellence in your technical breakdowns of a subject, especially cryptography (go figure ;).

80% of the RSA implementations on the Internet are insecure because they use the default padding

So, now that I've hopefully buttered you up enough, I'm hoping you have a reference to share, because if that's true, it's pretty damn scary.

[Smirnoff]

I hope Durov brothers are taking notes. Making a half-baked Facebook clone is not the same as making a fully-secured messaging system.

PS: These guys are still copying Facebook. Facebook released a messaging app, so these guys did the same. But, hey, Telegram is different because it uses MITM and it's "secure".

[11001]

"200% secure".

[DavidShahoumian]

> half-baked Facebook clone

It is better than Facebook in every possible way.

Have you actually ever used VK (both the site and the mobile apps)?

[Smirnoff]

Glad you asked. I used to use Vkontakte (and Odnoklassniki btw) in the past. Vkontakte has always been in the catchup position with "missing" or "out-of-blue broken" features on a surprisingly consistent basis.

Now, I won't discuss these missing/broken features here. You can look them up on their app's comments section. But I will leave you with one very important thing about privacy:

VK shows when you were online the last time. VK also shows you online if you login without an ability to turn it off! Great for stalkers and unfortunate for those who wouldn't want to receive unwanted conversations.

So I am very reluctant to trust someone, who really doesn't get privacy to build a messaging system with security and privacy in mind. Because we clearly view privacy differently.

[new_test]

> It is better than Facebook in every possible way.

Even if it were true, your statement still doesn't contradict GP's assertion.

[DavidShahoumian]

By that logic one could state that, for instance, Chrysler cars are "Ford clones" because Ford was the first manufacturer to become very popular and commercially successful.

[jaekwon]

> the biggest problem is that the SHA1 digest of a message is not an authenticator of that message, because an attacker can generate the same digest given only the contents of the message.

Curious, if the secret token comes after the message & there is proper delimiters to separate the message from the secret, where is the vulnerability?

Take a look at this link: https://blog.jcoglan.com/2012/06/09/why-you-should-never-use...

Am I correct to think that the example cited is bad? It appears that it would be a strong MAC because of the reasons that I cited.

[TelegramApp]

> 1. The biggest problem is that the SHA1 digest of a message is not an authenticator of that message, because an attacker can generate the same digest given only the contents of the message.

Please note that a message to be encrypted would not only contain the actual text sent, but also at least the server salt, session id, message sequence number, message length and precise time.

This complete data set could be theoretically obtainable only from either server or client memory, therefore the fact that an attacker has this kind of data implies that a successful attack had already taken place. Hence the question — why didn't that attacker take the auth_key right away?

On top of that, the present setup doesn't present any identifiable threats, because even if you could get a message with a given SHA1, you would still not know which message was really transmitted out of the possible matching set (or rather out of the 2^(L-160) messages for a message with the length of L bits).

Regardless of this fact, we do agree that strengthening this point would be logical in view of possible future developments in code-breaking. Thank you.

> 2. The last time your cryptosystem was discussed on HN, I provided a link to a thread in which Jutla laid out a simple, devastating attack on the mode in ASCII text in a mailing list post. You didn't respond.

I'm afraid, this is not true. You must mean this comment [0], and we did respond, days ago.

Today I can only repeat that we do not use IGE as MAC. The attack described there [1] is irrelevant for our setup. A question for you, by the way: is your position that using CBC instead of IGE in our case would make the protocol more secure or less secure?

[0] https://news.ycombinator.com/item?id=6918015

[1] https://groups.google.com/forum/#!topic/sci.crypt/4bkzm_n7UG...

> 3. Technical attributes of your RSA usage appear incompetent. RSA padding is not optional; 80% of the RSA implementations on the Internet are insecure because they use the default padding (PCKS1v1.5) which was carefully designed (in the 90s) to resist attacks, but missed some. You use ad-hoc padding.

We thanked you for feedback on padding two days ago [2] and noted that we were in the process of strengthening this point by moving to OAEP.

Still, the random padding already in use in MTProto is rather robust. The reason for this is that the RSA in DH is only used one way and ONLY with the public key. An attack on the private key would not be possible in this case, since it is not being used for transmission. So the sole possible attack would be MITM, which would imply deciphering RSA in real-time. If you are aware of other attacks that could harm this design, please tell us.

For the moment getting the RSA key with a microphone in traditional setups that store private RSA keys on client devices looks like a more real threat than what is described above. In our case private RSA keys are neither stored, nor used on the client.

[2] https://news.ycombinator.com/item?id=6918634

[tptacek]

You can't simply use CBC without a MAC either. The generic composition of CBC with HMAC and randomized explicit IVs is strong assuming you've dealt with side channels.

But a modern cryptosystem wouldn't use CBC either; it would use a AEAD mode, like AES-GCM or AES-OCB. A very, very modern system would use a native stream cipher like Salsa20 and a polynomial MAC like UMAC or GMAC or Poly1305. No cryptosystem in the world would use IGE mode plus SHA1.

There is no way around the fact that SHA1 with a bunch of semisecrets is not a real MAC. I have absolutely no idea why you would argue this point, but the fact that you do argue it is extraordinarily damning. I have never seen a project anywhere make so many mistakes and then confront such simple, straightforward, observations as "SHA1 is by itself not a MAC" with fierce arguments. The normal way of wiggling out of this problem is to fix your protocol. But your team clings tenaciously to a broken design. Why? Why? Why would you do that? How would anybody ever trust a cryptosystem designed by a team that would do that?

[tedunangst]

But your team clings tenaciously to a broken design. Why?

Maybe we're seeing the beginning of the "I'm going to do exactly the opposite of whatever the NSA tells me to do" era. The NSA says to use a MAC, so I'm not going to use a MAC!

[paveldurov]

If the advice comes from tptacek, you should probably do the opposite. He insisted this was NOT a backdoor:

https://news.ycombinator.com/item?id=6944118

[tptacek]

No, that's not at all what I said, but I despair of explaining the distinctions to someone who thinks AES-IGE+SHA1 and unpadded RSA is a sound design.

[moocowduckquack]

Hey, but now he knows that you are planning to do the opposite of what he says, presumably he will start giving you good advice, just to trick you.

The reason that people are so cynical about your custom solution is that being completely and utterly cynical about custom solutions, unless the architects can defend the solution rigorously, is the only sane approach in cryptography.

[Smirnoff]

Pavel, showing that he was wrong once in the past doesn't invalidate his multiple points he made now (or in the past).

[paveldurov]

> But a modern cryptosystem ... would use a AEAD mode, like AES-GCM

But really, it is funny how rigidly you stick to NSA Suite B Cryptography http://en.wikipedia.org/wiki/NSA_Suite_B_Cryptography

That, your fierce battle against everything unconventional and the fact that you get emotional instead of actually proving your point makes me think some "best practices" are indeed intentionally promoted in the crypto-community (https://news.ycombinator.com/item?id=6938622)

Disclaimer. I'm not an employee or shareholder in Telegram. I support them like I support some other non-profits like Wikimedia Foundation. As a reader here I would prefer to see an actual mathematical proof of how a certain system could be hacked instead of rhetoric like "No cryptosystem in the world would use...", "the fact that you do argue it is extraordinarily damning" or "Why? Why? Why would you do that?".

[StavrosK]

Because, with cryptography, the onus is on you to prove that your system is secure, not on other people to prove that it is broken. Everyone tells you there are many hints that your system is not secure, and you just go "well you can't prove it isn't, so there".

[jaxb]

Do you truly need to ad-hominem attack tptacek? You sound pretty much like pseudoscientists when they blame mainstream science being too rigid and not accepting their groundbreaking theories.

[paveldurov]

Scientific approach is exactly what I'm calling for here. When a cryptographer resorts to arguments like "this algorithm won't work because it is not common/modern/accepted" without providing an exact way to break it, it doesn't sound like scientific approach to me. It's more like the religious mindset of someone who rigidly worships some limited list of tools (e.g. "NSA Suite B Cryptography") and punishes anyone who is independent enough to deviate from it.

[earthrise]

In cryptography, the burden of proof is on the one proposing the system. It's up to the system designer to prove it secure. The reason why we stick to things like encrypt-then-HMAC, rather than rolling our own protocol, is that they HAVE been PROVEN secure. There are rigorous proofs [1,2] that HMAC and encrypt-then-HMAC are secure, assuming the underlying primitive is secure. There are no such proofs for Telegram's protocol, and there are many "smells" indicating attacks are possible, and I'm sure you'll see some actual examples soon.

[1] https://eprint.iacr.org/2006/043.pdf [2] http://cseweb.ucsd.edu/~mihir/papers/oem.pdf

Cryptography is HARD. It's so hard that it's hard to understand how hard it is. A large part of becoming a cryptographer is just learning how hard it is, and that you NEED security proofs, because it's just too easy to screw up.

I understand you're frustrated, but there's no need for the ad hominem attacks. tptacek is giving you good advice. We all want to see good crypto getting used. So why don't we work together to fix it instead of wasting our time defending a broken system? Honestly, replacing your protocol with encrypt-then-HMAC or the protocol from TextSecure isn't that big of a change, and it would make Telegram a lot better. So why not do it?

[new_test]

Pavel, folks here are being hard on you guys because historically, 9 out of 10 times "independent thinkers" who roll out their own crypto stacks get something wrong. That's why if you want to market your app to this crowd, you'll have a hard time selling something that is not what is a currently recommended crypto stack. Emphasizing that it is the NSA who recommends it is just a pasive-aggressive conspiracy theorizing. It may very well be the case that the NSA have ways of cracking their "Suite B", but we have no evidence of that, and if they do, do you really think that your ad-hoc solution would do much better against them?

[kpierre]

So as I understand, you do agree that moxie's mock protocol ( http://thoughtcrime.org/blog/telegram-crypto-challenge/ ), which he designed to be as awful as possible, is as secure as Telegram's mtproto? There's no exact way to break it either, it's just as new, it doesn't use 'limited set of tools' too, both don't have any mathematical proofs. By your logic, I can't see how is it different to mtproto then? How do we know you don't have a protocol just like his?

[tptacek]

I like this. "I'm calling for a scientific approach". Meaning, we throw out the last 20 years of scientific work on cryptography and start over from first principles, because the weight of the literature is inconvenient for your argument. It's an interesting tactic you've invented, and I'm surprised I haven't seen it in client change denial posts.

[phaus]

A large number of people who know what they are talking about have stated to you in the clearest terms possible that when it comes to cryptography and security systems, it is appropriate to place the burden of proof on the creators. It isn't an opinion, its a fact agreed on by every competent security practitioner on the planet. If you are going to continue to ignore this, no one is going to take anything you say about cryptography seriously.

Its not about dogma, its about safety. The fact that you fail to understand that is a testament to your inability to contribute to a meaningful conversation about security.

[jaxb]

I'm sorry but I have to ask:

Can you prove that you indeed are Pavel Durov of VK?