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…
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…
> 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…
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…
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…
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 here [0], and now here as well [1]). 1.…
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…
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…
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) The server now supports OAEP, although…
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…
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 attacks on this setup, please let us…
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…
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…
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…
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…
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 with the likes of WA, you also need be…
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…
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…
> 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…
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…
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…
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 here [0], and now here as well [1]). 1.…
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…
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…
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) The server now supports OAEP, although…
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…
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 attacks on this setup, please let us…
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…
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…
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…
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…
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 with the likes of WA, you also need be…