[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.

[paveldurov]

Well, when some of this "research" you promote ends up being backdoors planted by NSA (http://reut.rs/192XWwG), one has to be cautious.

Personally, I am more comfortable with 70s algorithms like Diffie-Hellman that have known and well-researched weaknesses. The "modern" algorithms actively promoted by US security firms after 9/11 are not time-tested, to say the least.

[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?