5 ms·

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 awa

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 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). But for the technically minded we provided rather detailed documentation for our protocol: http://core.telegram.org/mtproto http://core.telegram.org/mtproto and API: http://core.telegram.org/api http://core.telegram.org/api 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?

huhtenberg 13y ago
> this protocol is the result of thougtful and prolonged work of professionals. Pray tell, why replay protection is done after decryption.
- TelegramApp 13y ago
  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.
  - rblaze 13y ago
    Replay protection isn't about DoS attacks. Replay protections is about re-injecting previous messages to confuse recipient.
  - phaus 13y ago
    Well, you just made it painfully clear that at least one member of your team doesn't understand what a replay is. In light of that, why would anyone in their right mind use a security product your organization developed?
    - danabramov 13y ago
      Please mind that Telegram team are not native English speakers.
      - phaus 13y ago
        Ah, that makes more sense then them not knowing what a replay is. Their writing is good enough that I didn't notice they weren't from an English speaking country.
moxie 13y ago
> 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. IGE was the first attempt at an "authenticating encryption mode," originally for Kerberos. It was a failed attempt (it does not provide integrity protection), and had to be removed. That was the beginning of a 20 year quest for an authenticating encryption mode that works, which recently culminated in modes like OCB and GCM. I don't see any integrity protection documented anywhere in your protocol spec, so if you're relying on IGE, it's broken. What's more, any "problems" with CBC (I assume you're referring to padding oracle attacks) are not specific to CBC, and are endemic to IGE as well. > 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. I don't think their academic credentials or the amount of time they spent on this are the important metrics. If you're trying to suggest that they're thoughtful, the best metric for demonstrating that would be something like a proof for the (honestly naive-looking) KDF they made up. In essence, the protocol seems to reflect many choices that anyone familiar with the field can immediately identify as suggesting a lack of understanding. It could be that these are simply brilliant moves that we non-ACM champions are too primitive to understand, but if that's true, you need to justify them with proofs in order to support them. Otherwise we're going to interpret them for how they appear. > 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. Could you describe how your projects objectives are inconsistent with a protocol ratchet like Axolotol or the full TextSecure protocol?
- tptacek 13y ago
  Regarding IGE: Gligor and Donescu, 1999; a summary on a mailing list of the attack: https://groups.google.com/forum/#!topic/sci.crypt/4bkzm_n7UGA https://groups.google.com/forum/#!topic/sci.crypt/4bkzm_n7UG... Long story short: you get integrity protection from IGE by relying on the fact that a bit error anywhere in the stream will irrevocably corrupt the rest of the stream, so you create an authentication code by sticking an all-zeroes block or (like I think Telegram does) a message digest to the end of the stream. But it's possible with carefully chosen errors to first corrupt an IGE stream and then recover it, so that the remainder of the message after the corruption (including the "MAC" tag) will remain intact. IGE is an extremely weird, and, at this point I'll venture: bad choice for a 2013-2014 cryptosystem.
tptacek 13y ago
What's the message format you're using for RSA? I see RSA in the "pq" code of your Java client library; I see you asking Java for an "unpadded" instance of the RSA encryptor; I see you using RSA in its encrypting operation (not signing). Great crypto software avoids RSA. Good crypto software uses OAEP when RSA is used to encrypt. Crappy crypto software (see: DNSSEC) uses PKCS1v1.5. What are you using? I didn't look carefully; I have probably missed something. Please explain how you are using RSA in the handshake/authentication for your protocol. Like Moxie said: it's not the underlying algorithms you use; it's the constructions you use to to them together, and to the data you're protecting. Incidentally, "I refuse to respond to comments from people who have only looked at my system for a couple minutes" is not a habit of highly effective cryptographers.
- TelegramApp 13y ago
  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 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!
  - tptacek 13y ago
    This is a brand new application, right? Why is it built on '90s (or, worse, '70s) cryptography? You need to publish the server-side source code for me to have any chance of making sense of this. I only see the client side of the connection in your source code, not the server response.
alandarev 13y ago
Speaking of masses... Is vkontakte [1] (russian social site) being somehow involved? I got confused by the illustrative images strongly resembling the vkontakte images. Not to dive into Russian folk, but those look too culturally localized. [1]: http://vk.com http://vk.com
- notdang 13y ago
  vkontakte and telegram shares the same founder: Durov
liliakai 13y ago
Gentlemen? Sexist.
jackmaney 13y ago
"The team behind Telegram, led by Nikolai Durov, consists of six ACM champions, half of them Ph.Ds in math." In what areas of mathematics did these PhDs specialize? I hold a PhD in mathematics, but I would not feel comfortable rolling my own cryptographic algorithms for use in production (I'm a commutative algebraist by training).
jackmaney 13y ago
"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?" Yes, because we all know that there are no women who can write code or analyze cryptographic algorithms. [rolls eyes]

huhtenberg 13y ago

> this protocol is the result of thougtful and prolonged work of professionals. Pray tell, why replay protection is done after decryption.

TelegramApp 13y ago
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.
- rblaze 13y ago
  Replay protection isn't about DoS attacks. Replay protections is about re-injecting previous messages to confuse recipient.
- phaus 13y ago
  Well, you just made it painfully clear that at least one member of your team doesn't understand what a replay is. In light of that, why would anyone in their right mind use a security product your organization developed?
  - danabramov 13y ago
    Please mind that Telegram team are not native English speakers.
    - phaus 13y ago
      Ah, that makes more sense then them not knowing what a replay is. Their writing is good enough that I didn't notice they weren't from an English speaking country.

moxie 13y ago

> 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. IGE was the first attempt at an "authenticating encryption mode," originally for Kerberos. It was a failed attempt (it does not provide integrity protection), and had to be removed. That was the beginning of a 20 year quest for an authenticating encryption mode that works, which recently culminated in modes like OCB and GCM. I don't see any integrity protection documented anywhere in your protocol spec, so if you're relying on IGE, it's broken. What's more, any "problems" with CBC (I assume you're referring to padding oracle attacks) are not specific to CBC, and are endemic to IGE as well. > 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. I don't think their academic credentials or the amount of time they spent on this are the important metrics. If you're trying to suggest that they're thoughtful, the best metric for demonstrating that would be something like a proof for the (honestly naive-looking) KDF they made up. In essence, the protocol seems to reflect many choices that anyone familiar with the field can immediately identify as suggesting a lack of understanding. It could be that these are simply brilliant moves that we non-ACM champions are too primitive to understand, but if that's true, you need to justify them with proofs in order to support them. Otherwise we're going to interpret them for how they appear. > 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. Could you describe how your projects objectives are inconsistent with a protocol ratchet like Axolotol or the full TextSecure protocol?

tptacek 13y ago
Regarding IGE: Gligor and Donescu, 1999; a summary on a mailing list of the attack: https://groups.google.com/forum/#!topic/sci.crypt/4bkzm_n7UGA https://groups.google.com/forum/#!topic/sci.crypt/4bkzm_n7UG... Long story short: you get integrity protection from IGE by relying on the fact that a bit error anywhere in the stream will irrevocably corrupt the rest of the stream, so you create an authentication code by sticking an all-zeroes block or (like I think Telegram does) a message digest to the end of the stream. But it's possible with carefully chosen errors to first corrupt an IGE stream and then recover it, so that the remainder of the message after the corruption (including the "MAC" tag) will remain intact. IGE is an extremely weird, and, at this point I'll venture: bad choice for a 2013-2014 cryptosystem.

tptacek 13y ago

What's the message format you're using for RSA? I see RSA in the "pq" code of your Java client library; I see you asking Java for an "unpadded" instance of the RSA encryptor; I see you using RSA in its encrypting operation (not signing). Great crypto software avoids RSA. Good crypto software uses OAEP when RSA is used to encrypt. Crappy crypto software (see: DNSSEC) uses PKCS1v1.5. What are you using? I didn't look carefully; I have probably missed something. Please explain how you are using RSA in the handshake/authentication for your protocol. Like Moxie said: it's not the underlying algorithms you use; it's the constructions you use to to them together, and to the data you're protecting. Incidentally, "I refuse to respond to comments from people who have only looked at my system for a couple minutes" is not a habit of highly effective cryptographers.

TelegramApp 13y ago
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 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!
- tptacek 13y ago
  This is a brand new application, right? Why is it built on '90s (or, worse, '70s) cryptography? You need to publish the server-side source code for me to have any chance of making sense of this. I only see the client side of the connection in your source code, not the server response.

alandarev 13y ago

Speaking of masses... Is vkontakte [1] (russian social site) being somehow involved? I got confused by the illustrative images strongly resembling the vkontakte images. Not to dive into Russian folk, but those look too culturally localized. [1]: http://vk.com http://vk.com

notdang 13y ago
vkontakte and telegram shares the same founder: Durov

liliakai 13y ago

Gentlemen? Sexist.

jackmaney 13y ago

"The team behind Telegram, led by Nikolai Durov, consists of six ACM champions, half of them Ph.Ds in math." In what areas of mathematics did these PhDs specialize? I hold a PhD in mathematics, but I would not feel comfortable rolling my own cryptographic algorithms for use in production (I'm a commutative algebraist by training).

jackmaney 13y ago

"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?" Yes, because we all know that there are no women who can write code or analyze cryptographic algorithms. [rolls eyes]