8

For those who don't know: Telegram is a partially open source Whatsapp alternative (Server is closed source) which offers secret chats and normal chats. Secret chats are encrypted with Diffie-Hellman key exchange and are end-to-end encrypted. One can verify his peer's signature using a barcode. Normal chats are not end-to-end encrypted, but have the benefit of being synced between one's devices.

Telegram has been widely criticized for using a brand new protocol, MTProto. Whether MTproto is actually secure or not is out of the scope of this question, let us assume it is insecure.

Since DH is used in secret chats, will a compromise of MTProto compromise secret chats? Are DH and MTproto coupled in such a way that if MTProto fails, DH fails? Or is it layered so that the two must fail for secret chats to become vulnerable?

In short, if one does not trust MTProto, can one still trust secret chats thanks to DH?

Note: MTProto also uses DH for device registeration, this is unrelated.

Useful official documents:

Detailed description of MTProto

Technical FAQs

Secret chats

Update:

Anton Garcia Dosil stated that DH is just a way to distribute keys and is not an encryption method itself. This is definitely true, and I apologize for being a bit vague here. A clearer formulation of my question would be: Once the two peers exchange DH keys and begin end-to-end encryption, does MTProto use an encryption method which is known to be secure? or does it use yet another home brewed encryption scheme? If it does use a known encryption method X for secret chats, Are X and MTproto coupled in such a way that if MTProto fails, X fails? Or is it layered so that the two must fail for secret chats to become vulnerable?

Improve this question
2
  • Note from the future. Telegram used a roll-your-own encryption scheme which has proven to be as safe as the typical roll-your-own encryption scheme. Several of Schneier's rules apply here, use with caution or not at all till you hear it's been fixed.
    – Fiasco Labs
    Nov 28, 2015 at 3:39
  • @FiascoLabs How many more years do we wait for someone to retrieve a plaintext message before we can call it "the future"? This thing is just as old as the signal protocol. The "it's going to break any day now" argument that I've been hearing from day one (and back then I thought it might be true) is wearing very thin. But it will never be wrong, so I guess people will just keep saying this forever because they have no other arguments to make against it?
    – Luc
    Nov 9, 2021 at 17:44

2 Answers 2

Reset to default
7
+150

The objective of Diffie-Hellman (I guess they authenticate DH somehow) is only key distribution.

The objective of MTProto is encryption.

Diffie-Hellman feeds MTProto with keys lets say. It is in a higher level. Although MTProto is 'broken', secure key establishment still takes place. So DH effectively does not fail in its purpose (key distribution).

Having said that, if you are able to break MTProto (say the keylength is small) by bruteforcing the keys in some manner, the issue is still of MTProto and not of DH.

The protocol is as strong as its weakest link. In this case if we think MTProto is unreliable, then the whole protocol is unreliable.

EDIT: Looking at the specification in MTProto. I'm not sure to understand the question completely but I believe that you ask if the 'atomic' elements of MTProto can loose effectiveness by poor coupling.

  • AES-256 is used for encryption, this is acceptable.

  • SHA1 as a hash function is acceptable at the moment.

  • Diffie-Hellman for key establishment ok (provided there is authentication). The key established later derives one key for encryption with freshness (time and sequence number) to provide entity authentication.

The only issue I can see for this protocol is if DH is not authenticated. If this is not the case, anyone would be able to generate the encryption key (both with shared-key obtained in a MITM and the source of freshness transmitted in clear).

For end-to-end they use AES-256 as well. The fingerprint looks kind of lame though (and re-uses the encryption key).

digest = md5(key + iv) fingerprint = substr(digest, 0, 4) XOR substr(digest, 4, 4)

In addition it seems they use AES in ECB mode, that kind of sucks as well, but still, overall the protocol seems 'OK' for normal users. If you are Snowden or Assange perhaps use something else just in case ;)

Improve this answer
4
  • I may be wrong, but I believe that AES 256 is used for communicating with the server and not for the end-to-end encryption. See this: core.telegram.org/api/end-to-end . Unfortunately, it is too technical for me to make sense of. My questions is regarding the end-to-end encryption.
    – Hello World
    May 15, 2014 at 7:28
  • The DH keys can be authenticated by the end user, there is no issue here.
    – Hello World
    May 15, 2014 at 7:35
  • For end to end they use AES-256 as well. The fingerprint looks kind of lame though (and re-uses the encryption key). digest = md5(key + iv) fingerprint = substr(digest, 0, 4) XOR substr(digest, 4, 4)
    – Anton Garcia Dosil
    May 15, 2014 at 17:51
  • 1
    I decided to give you the bounty because you tried hard to assist and I don't want it to go to waste. But I will not choose this as the best answer because it left me right where I started: It seems safe, but I'm not sure.
    – Hello World
    May 18, 2014 at 9:24
0

They use AES in IGE mode not in ECB-mode. But nevertheless it shouldn't be ok for normal users and better than no block cipher mode.

Data is encrypted with a 256-bit key, aes_key, and a 256-bit initialization vector, aes-iv, using AES-256 encryption with infinite garble extension (IGE)

by Telegram

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .