5 ms·

Reminds me of Telegram’s ad-hoc design with so many primitives lashed together without any engineering or analysis. “More crypto” in your implementation is rare

Reminds me of Telegram’s ad-hoc design with so many primitives lashed together without any engineering or analysis. “More crypto” in your implementation is rarely better for security. This is a great teaching example for the “don’t roll your own crypto” proponents.

winterdeaf 4y ago
The same research group working on the Telegram MTProto security analysis is behind these attacks on MEGA! (I should add: disclosure, I work there too.)
- taneq 4y ago
  Interesting! While you're here, is there anything you can add to the general debate about Telegram's crypto design? I see a lot of people here disparaging it, but nothing really from Telegram to explain what choices were made or why.
  - winterdeaf 4y ago
    To put it in Igor's words, it is like "somebody baked a cake following a recipe, but without ever having tasted or seen a real cake". The crypto design is brittle, but the practical attacks are somewhat limited. The reason why it's so disparaged by cryptographers it because it ignores several decades of cryptographic advances -- the whole saga of attacks on SSL / TLS<=1.2 taught us that key separation and clear protocol composition boundaries are important, but Telegram fails disastrously at these. Security proofs should be made before a protocol is used, not as an afterthought. The real reason why I would not recommend Telegram is that chats (by default) and group chats (by necessity) are not encrypted. Telegram's servers will be eventually breached by someone. A malicious actor will be hired as a software engineer, or as an intern. When this happens, all you ever wrote in Telegram will be a plaintext at their disposal -- unacceptable in 2022, and post-Snowden.
mappu 4y ago
I think this level of key management is relatively simple for a production application. There are not really too many pieces and certainly no unnecessary steps (the mitigation recommendation was to add more keys, not fewer). The interesting part is really just the first step - starting with a user's password, to statically derive a service-authentication key and a data-encryption key that the service provider ostensibly never sees. At $DAYJOB we independently came up with this same zero-knowledge solution too, using slightly different primitives. Ideally there'd be some well-reviewed zero-footgun nacl.SecretBox()-style thing for this use case, but there simply isn't.
- api 4y ago
  Cryptographers say "don't roll your own," but there is a real poverty of well designed clean easy to use cryptographic libraries that provide well designed building blocks with clear instructions or fully baked well designed protocols. Most cryptographic libraries are arcane and hard to use, and the user experience around things like TLS certificate management is horrible. Most people face a choice between rolling their own crypto or not using it at all.
  - tptacek 4y ago
    Is this true, or is it true of people who don't want to use libsodium, Ring, the Go Seal/Unseal AEAD interface, or KMS because it doesn't feel as cool as inventing your own authentication proof protocol?
    - na85 4y ago
      >Ring Can you provide a link? That one's hard to Google.
      - tptacek 4y ago
        https://github.com/briansmith/ring https://github.com/briansmith/ring
- tptacek 4y ago
emptysongglass 4y ago
MTProto 2 uses standard primitives. I'd also like to point out that not "rolling your own crypto" falls apart the moment you ask who rolled whoever's "blessed" crypto. How this trite saying ever got any traction without pushback is beyond me.
- tptacek 4y ago
  It does? From Telegram's documentation, it looks like it's still using AES IGE. Telegram, meanwhile, can as far as I understand it encrypt only one-to-one private messages, not groups, and does so on an opt-in basis, in part because their "standard primitives" don't support the usage model of modern secure messengers, which do multiple levels of cryptographic ratcheting using actually-standard KDFs, hashes, authenticated ciphers, and authenticated elliptic curve key exchanges. Further, outside of Signal, whose authors won the RWC Levchin Prize for their design work, the other modern secure messengers essentially don't roll their own: they draft off the design work Signal did. Which is a good thing for their users. The alternative course, of coming up with your own special snowflake crypto, gets you papers like the one we're commenting on.
  - jorvi 4y ago
    For all the disparaging MTProto gets, it still hasn’t ever been broken in practice. That doesn’t mean it was a great idea for them to pseudo-‘roll their own’, but it doesn’t deserve the vehement hatred that is constantly poured over it.
    - tptacek 4y ago
      For all the disparaging Mega got, it hadn't been broken until today.
- tatersolid 4y ago
  The Telegram protocol I’m so critical of was v1 which included DH, RSA, AES in IGE mode, and SHA1. All used in random ways with key sub setting, reuse of some key bits for multiple purposes, etc. https://core.telegram.org/mtproto/description_v1 https://core.telegram.org/mtproto/description_v1 I honestly haven’t looked into anything newer from Telegram because it was pretty clearly a tire-fire and Signal was already a thing.

winterdeaf 4y ago

The same research group working on the Telegram MTProto security analysis is behind these attacks on MEGA! (I should add: disclosure, I work there too.)

taneq 4y ago
Interesting! While you're here, is there anything you can add to the general debate about Telegram's crypto design? I see a lot of people here disparaging it, but nothing really from Telegram to explain what choices were made or why.
- winterdeaf 4y ago
  To put it in Igor's words, it is like "somebody baked a cake following a recipe, but without ever having tasted or seen a real cake". The crypto design is brittle, but the practical attacks are somewhat limited. The reason why it's so disparaged by cryptographers it because it ignores several decades of cryptographic advances -- the whole saga of attacks on SSL / TLS<=1.2 taught us that key separation and clear protocol composition boundaries are important, but Telegram fails disastrously at these. Security proofs should be made before a protocol is used, not as an afterthought. The real reason why I would not recommend Telegram is that chats (by default) and group chats (by necessity) are not encrypted. Telegram's servers will be eventually breached by someone. A malicious actor will be hired as a software engineer, or as an intern. When this happens, all you ever wrote in Telegram will be a plaintext at their disposal -- unacceptable in 2022, and post-Snowden.

mappu 4y ago

I think this level of key management is relatively simple for a production application. There are not really too many pieces and certainly no unnecessary steps (the mitigation recommendation was to add more keys, not fewer). The interesting part is really just the first step - starting with a user's password, to statically derive a service-authentication key and a data-encryption key that the service provider ostensibly never sees. At $DAYJOB we independently came up with this same zero-knowledge solution too, using slightly different primitives. Ideally there'd be some well-reviewed zero-footgun nacl.SecretBox()-style thing for this use case, but there simply isn't.

api 4y ago
Cryptographers say "don't roll your own," but there is a real poverty of well designed clean easy to use cryptographic libraries that provide well designed building blocks with clear instructions or fully baked well designed protocols. Most cryptographic libraries are arcane and hard to use, and the user experience around things like TLS certificate management is horrible. Most people face a choice between rolling their own crypto or not using it at all.
- tptacek 4y ago
  Is this true, or is it true of people who don't want to use libsodium, Ring, the Go Seal/Unseal AEAD interface, or KMS because it doesn't feel as cool as inventing your own authentication proof protocol?
  - na85 4y ago
    >Ring Can you provide a link? That one's hard to Google.
    - tptacek 4y ago
      https://github.com/briansmith/ring https://github.com/briansmith/ring
tptacek 4y ago

emptysongglass 4y ago

MTProto 2 uses standard primitives. I'd also like to point out that not "rolling your own crypto" falls apart the moment you ask who rolled whoever's "blessed" crypto. How this trite saying ever got any traction without pushback is beyond me.

tptacek 4y ago
It does? From Telegram's documentation, it looks like it's still using AES IGE. Telegram, meanwhile, can as far as I understand it encrypt only one-to-one private messages, not groups, and does so on an opt-in basis, in part because their "standard primitives" don't support the usage model of modern secure messengers, which do multiple levels of cryptographic ratcheting using actually-standard KDFs, hashes, authenticated ciphers, and authenticated elliptic curve key exchanges. Further, outside of Signal, whose authors won the RWC Levchin Prize for their design work, the other modern secure messengers essentially don't roll their own: they draft off the design work Signal did. Which is a good thing for their users. The alternative course, of coming up with your own special snowflake crypto, gets you papers like the one we're commenting on.
- jorvi 4y ago
  For all the disparaging MTProto gets, it still hasn’t ever been broken in practice. That doesn’t mean it was a great idea for them to pseudo-‘roll their own’, but it doesn’t deserve the vehement hatred that is constantly poured over it.
  - tptacek 4y ago
    For all the disparaging Mega got, it hadn't been broken until today.
tatersolid 4y ago
The Telegram protocol I’m so critical of was v1 which included DH, RSA, AES in IGE mode, and SHA1. All used in random ways with key sub setting, reuse of some key bits for multiple purposes, etc. https://core.telegram.org/mtproto/description_v1 https://core.telegram.org/mtproto/description_v1 I honestly haven’t looked into anything newer from Telegram because it was pretty clearly a tire-fire and Signal was already a thing.