Hacker News Reader

Comment by tatersolid | Hacker News Reader

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.

View on HN

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

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.

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.

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.

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.

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?

>Ring

Can you provide a link? That one's hard to Google.

https://github.com/briansmith/ring

I'm not super entirely clear on how this whole Mega system works, and maybe you understand it better, but is there a reason they couldn't have just run an Augmented PAKE between the client and the server to establish authentication and create a cryptographically secure transport for recovering key blobs, and then used any key-wrap encryption, like AES-SIV, based on any KDF of a password --- ideally a second password --- to encrypt the node keys themselves?

There is a whole hellacious amount of mechanism in this protocol that doesn't seem necessary at all. I don't know if doing it simply would involve more keys or less keys but it would certainly seem to involve fewer concepts and less ad-hoc invention --- PAKEs are a solved problem, KDFs are a solved problem, key-wrap encryption is a solved problem.

Instead they came up with unpadded RSA, ECB-encrypted key blobs, a single shared key for all the blobs, a post-back proof that is just that broken RSA piped directly back to the server. I don't know, seems pretty bad?

There's a secure channel here (TLS) and then the blob encryption all happens clientside, so i don't think a PAKE-type solution is less mechanism, but i do recognize your expertise on that. Where do you think it would fit in?

Backup and sync-type software has the interesting engineering requirement that it is expected for the user's device to get completely lost/stolen/wiped, so any key material must be reproducible from the user's password.

Password -> KDF(1) gives you a password-alike: used for logins, server treats this kdf output as a password and stores a bcrypt/argon hash of it, as you would normally expect from a run-of-the-mill webapp.

The client generates a random data encryption key; seals it with the password; and then submits the sealed version to be stored in the user's profile on the web server.

The web server can't unseal the original data encryption key without the original password, and it never sees that, only the KDF(1) version of it.

That's all they've really done here. There is one more level of key indirection for the blobs themselves that i think is irrelevant but maybe useful for key rotation. Totally agree that unpadded RSA and ECB suck as primitives - they were bad choices then, they are bad choices now, and AEAD is a no-brainer upgrade (EDIT: and would close the post-back oracle) - but aside from picking better primitives the mechanism really does seem okay to me. I'd love to hear more from you though,

I'm a little lost, because what they came up with is a complicated and naive key proof that allowed attackers to recover the RSA key. There was no code that already implemented this weird ECB key-wrap and RSA key-proof scheme they came up with; they had to write it all themselves, rather than just grabbing a PAKE and an AEAD from a library. And the consequence of them doing that was that they had key recovery attacks like three levels deep.

You'd need to implement SIV in the browser yourself, not sure if that's a good idea either. Subtle crypto has support for AES-based key wrapping, but AES-GCM seems to be good enough for most cases, even AWS uses that to protect master keys in AWS KMS [1]. Using augmented PAKE for authentication would be nice of course, but that needs to implemented manually in the browser as well. In my understanding it also requires providing the server with a separate user ID, which you would either need to derive from the password or store with the download link.

I think if you have a download link of the form https://foo.bar/#abcdef... you can simply put a large random value there (e.g. 128 bit), use HKDF to derive an ID and an encryption key, use the ID (shared with the server) to store/fetch encrypted data on/from the server and the key (not shared with the server) to encrypt/decrypt it on the client side. This would assume that the ID transmitted to the server over a secure channel and that brute-forcing of IDs to download encrypted data is not practical. Such a scheme would not be secure though if you derived the ID and key from a user-provided password, as the server could then brute-force the password from the ID the client provides.

1: https://rwc.iacr.org/2018/Slides/Gueron.pdf

> well-reviewed zero-footgun nacl.SecretBox()-style thing for this use case, but there simply isn't.

You'd be surprised, but I've seen designers who managed to shoot themselves in the feet with SecretBox() calls alone. Anything more complex than using a library that does the crypto for you calls for an external/crypto team review.

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.

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.

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.

For all the disparaging Mega got, it hadn't been broken until today.

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

I honestly haven’t looked into anything newer from Telegram because it was pretty clearly a tire-fire and Signal was already a thing.

Reply on news.ycombinator.com