TelegramApp

There is one exception to this: people will see you online for a brief period of time right after you send THEM a message (otherwise it would feel like talking to a wall).

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?

Now, again, could I somehow direct your attention away from speculations and to what we are ACTUALLY doing (as, again, documented here [0], and now here as well [1]).

1. We are not doing plain encrypt-and-mac.

2. The SHA1 in question is for raw unencrypted data.

3. The message key is SHA1-dependent.

4. Note that the AES key and iv depends on that SHA1.

This can be described as a generic composition of cipher with ciphertext, encrypted by a MAC. The resulting data-dependant variable key denies all common attacks.

As for KDF, what particular solution do you have in mind? And even then — certainly, alternative solutions exist, but we do not see how changing this point would affect our system as whole. [1] As stated before, we'd welcome any information on attacks that could in reality threaten the actual setup.

We are indeed using well-known older algorithms, created in the days when bandwidth and processing power were both a much rarer commodity. This has valuable side-effects for modern-day mobile development, provided one takes care of the known drawbacks.

The weakspots of the said algorithms are also well-known, and have been exploited for decades. We used these algorithms in such a combination that, to our best knowledge, prevents any known attack from possibly succeeding. Although we’d be grateful to see any evidence of the contrary (so far absent from this thread) and update our system accordingly.

While other ways of achieving the same cryptographic goals, undoubtedly, exist, we feel that the present solution is both robust and also sucсeeds at our secondary task of beating unencrypted messengers in terms of delivery time and stability.

1. Kindly be more specific about our RSA implementation. Please note, that we only use RSA with public keys, not private. If you are aware of any possible attacks on this setup, please let us know.

2. And what problems with IGE are you aware of? Any known attack? As far as we know, it is the ubiquitous CBC that has had issues. And by the way, Kerberos had to abandon PCBC - not IGE.

Thank you for the offer to join in the project you represent. However, we feel that what we are doing is going in a somewhat different direction and has its own potential.

The team behind Telegram, led by Nikolai Durov, consists of six ACM champions, half of them Ph.Ds in math. It took them about two years to roll out the current version of MTProto. Names and degrees may indeed not mean as much in some fields as they do in others, but this protocol is the result of thougtful and prolonged work of professionals.

The basic copy on telegram.org rightfully appears as simplistic to the Hacker News resident. It was written for the general public, since we want to bring secure messaging to the masses — not just to the security geek, who has it already (in oh so many forms).