Hacker News new | ask | show | jobs
by TelegramApp 4572 days ago
The reason for designing something new was this: in order for really secure messaging to catch on among the masses today — it needs not only be secure. When you want to compete with the likes of WA, you also need be fast and reliable on weak mobile connections.

TLS/HTTPS is slow and takes a lot of time to restore connection on fragile networks.

MTProto was born as a result of an experiment: whether it would be possible to create something that is both secure and fast.

Disclaimer: Unfortunately, I'm not Nikolay. But I do work for Telegram.

3 comments

This is all great, but it reads like a marketing speak. There was this imperfect world full of idiots, slow, ugly and dim lit and then we came along and lifted the gloom.

Sorry, you have to do better than "TLS/HTTPS is slow". Anything over TCP is slow on congested and lossy networks. That's given, but that's hardly a reason to reinvent the whole crypto stack.

How is your protocol superior / faster / better than DTLS with session resuming? Is it faster than IKE in Quick Mode or IKE v2, which are both datagram protocols designed to work over lossy networks? What are the inherent problems with adopting DTLS or IKE to your purposes? This is dead easy to do without touching original crypto design and it instantly removes all questions pertaining to the quality of your crypto design. So why not?

I'm not a professional cryptographer, but I know applied crypto well and I've seen my share of custom crypto designs. Virtually ALL of them are is a result of thinking that it's better and easier to invent something new than to diligently learn what exists and understand how it works. It's fine for some areas, but it is decidedly not a way to go in the cryptography domain.

>MTProto was born as a result of an experiment: whether it would be possible to create something that is both secure and fast.

I'd like to see some papers/surveys/case studies on the matter. Yes, it's an "experiment", doesn't mean it's a good idea to roll out your own implementation before performing (and publishing) extensive tests.

Not saying you're doing something wrong, just that security-oriented people (usually who'd be interested in your product) may want to know more than just "yes guys it's secure, trust us".

Even WA doesn't roll their own key deriviation scheme, they use PBKDF2+SHA1.