Yes, it DOES stop showing you as online. If you are not sharing your last seeen/online status with somebody, he will NOT see you online, regardless of the app they are using.
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).
One of the Telegram apps for Android did use Google Maps in http-mode. The issue was fixed within an hour, and the update is on its way to Play Market, containing several other security-related improvements.
At this moment we are working together with security experts on code review for our client applications. We awarded the person who discovered the bug and are designing a bug bounty program, which will be rolled out soon.
> 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?
> 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.
The contest, as proposed by Pavel, while limited for the moment, does cover an important issue as far as our users are concerned. And the scope will naturally expand with time, should Telegram be invulnerable under the current conditions (see contest FAQ: http://core.telegram.org/contestfaq).
Quoting a post by Pavel here on HN: "Telegram will always be interested in creating incentives for the crypto-community to check its security and provide feedback. So if you are waiting for tools to try, e.g., a MITM on Telegram and get your $200К, please stay tuned. It's @telegram on Twitter."
(https://news.ycombinator.com/item?id=6938987)
As for general critique of the protocol, please allow us to add a few vital corrections regarding the article (unfortunately, the author chose a platform that would not permit a direct comment).
> They use the broken SHA1 hash function.
SHA-1 isn't exactly broken. There is a theoretical paper from 2005 that describes a way to narrow down collision search from 2^80 to approx. 2^69 operations (http://people.csail.mit.edu/yiqun/SHA1AttackProceedingVersio...) with subsquent improvement to 2^63, but collisions won't help in the case at hand. In order to break the implementation in MTProto you would require generating a text with chosen SHA-1 (to our knowledge, this problem was not yet solved) — and even that wouldn't get one far, because of the server salt, session id and time.
> Some really weird stuff about factoring 64-bit integers as part of the protocol.
This weird stuff can be pretty effective as part of our DoS-protection scheme.
Meanwhile, we've expanded our Tech FAQ with responses to most common questions concerning MTProto's robustness against certain types of active attacks:
Kindly take at look at this technical FAQ that we've assebmled based on the conversations on Hacker News and elsewhere:
http://core.telegram.org/techfaq
No. What we mean is, as I've just noted in the reply to tptacek, that so far no attack was named that could harm the setup as described in our docs. And since this setup also delivers the performance that we require in terms of speed, we do not see why it would be necessary to change our approach to KDF.
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.
In order to clarify a few points in our setup, we've added this scheme to the protocol description page [0],[1].
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.
2. A passing look at the docs would reveal that we do not use IGE that way, and instead use SHA1 for integrity check (see 'message key' here: https://core.telegram.org/mtproto/description). The problems you mentioned as endemic to IGE used for integrity verification, are therefore irrelevant in this case.
As for KDF, going for slower provable algorithms used for each incoming\outgoing packet may be a preferred solution for projects aimed at the relatively small security crowd. But we don't really compete in this area, our competition is WhatsApp and other mass market messengers.
This version of the client is using manual padding with random bytes. This isn't too bad, considering the SHA1 presence.
(See #4 here: https://core.telegram.org/mtproto/auth_key)
The server now supports OAEP, although this has yet to find its way into the docs and clients. We will update. Thank you!
In terms of DoS possibilities, one doesn't need to replay old messages, they could just as easily send new ones or random garbage.
We could employ additional filtering techniques, but that increases processing time. And since modern hardware allows for very fast AES decryption, there is no particular gain in building additional layers of protection.
All that, naturally, implies that other anti-DoS measures are also being used.
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).
We would be glad to respond to criticism, but not on the level of "I looked at it for 4 minutes, maybe they didn't think about X" (as another guy in the comments below put it), or "why didn't you just use this?".
If anybody here can identify a specific point and prove that it is vulnerable and can be hacked a certain way, we are ready to respond and\or fix, if neccessary. Gentlemen?
MTProto still uses RSA, AES + DH. So I would disagree that what we have here means 'compromising security for speed and stability'. It is rather optimizing for speed and stability, while staying secure.
We have not 'rolled our own crypto'. We still use RSA, AES and DH.
I've changed the part in the FAQ that seems to be one of major sources of this controversy, so that it no longer reads "built from scratch". This was poorly applied marketing language — we do use time-tested security algorithms. Even though Telegram doesn't uses MTProto instead of HTTPS due to mobile speed and trust issues.
That is correct, Telegram does upload names and numbers — naturally, after receiving permission to do so. (see also: http://telegram.org/privacy)
Apart from identifying Telegram users among the user's friends, this also enables us to use proper names in notifications on the iPhone, as well as facilitates moving between devices.
But you have highlighted an important issue. Our android developer relied on the system prompts when it comes to uploading contacts, which is definitely not enough for the issue at hand. We will add another prompt in the coming version. (As well as update the GitHub code to the current generation soon, it's been becoming a little stale.)
Still, there are sometimes valid reasons for not re-using existing solutions.
In our case, we needed something that is both secure and competitive in comparison to mass market solutions in terms of speed, working on weak connections and usability.
Private keys for secret chats are only stored on the two participating devices.
As for server code — open sourcing the server code wouldn't really do much to improve trust. You would still have to trust us that we are using THAT code, not something different.
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).
See: https://telegram.org/faq#q-can-i-hide-my-last-seen-time And: https://telegram.org/faq#q-who-can-see-me-online