Viewing profile — TelegramApp

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…

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 sec…

> 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 t…

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, sho…

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 deliv…

Thanks for noticing, we fixed that yesterday.

> The consensus seems to be that you're doing.. Now, again, could I somehow direct your attention away from speculations and to what we are ACTUALLY doing (as, again, documented he…

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 day…

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/desc…

We use SHA1 (see 'message key' here: https://core.telegram.org/mtproto/description ). IGE is used instead of CBC.

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 ) …

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, …

Two questions for you: 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 at…

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,…

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 …

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 u…

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 solu…

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 wou…

Is anything wrong with it?

The main reason is speed. MTProto is designed to work fast on weak mobile connections. Another reason is security, with HTTPs you need to trust more parties.

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 wit…