Hacker News Reader

BEAST and CRIME are both chosen-plaintext attacks. They don't rely on the improper MAC composition in TLS CBC.

Lucky13 and POODLE are the chosen-ciphertext attacks.

EDIT: Some more details:

BEAST takes advantage of predictable IVs in SSLv3 and TLS 1.0. In these protocols, the IV for each new record is simply the last block of the previous record. An attacker monitoring traffic on the wire can use this predictability to build an encryption oracle and guess-and-check the contents of ciphertext blocks.

CRIME uses plaintext compression to its advantage. A message with longer common substrings will compress slightly better than one without, and this is reflected in the ciphertext length. An attacker can make adaptively chosen guesses at substrings included in the message to recover, e.g., session cookies.

D'oh. Sorry. It's release day here.

POODLE is the best example, I think.

It happens. :)

I agree, POODLE is a close analog.

Great takeaways from BEAST and CRIME.

For BEAST, my takeaway was to never introduce a dependency into a cryptosystem of any kind without thinking very carefully about the implications-- and if in doubt, don't do it. I also took away "don't be creative" -- boring crypto is best. Generating random IVs from a CSPRNG is boring. Reusing the last block is interesting, but there be dragons. Crypto should be boring, straightforward, and directly based upon the current state of the art best practices without introducing anything that hasn't been subjected to rigorous analysis. Complexity equals bugs, etc.

For CRIME the takeaway is the concise "never compress somethings secret together with something attacker-influenced." It means one must be careful in using compression together with encryption, and that if one is very highly paranoid it is probably best to leave compression out to err on the side of caution.

Nit: chaining IVs was the norm, used in a bunch of protocols, until the mid-2000s. It's obvious why you'd want to do it (saves space, and, conceptually, the IV is the negative-oneth ciphertext block anyways).

> TLS's Mac-then-encrypt CBC was known not to be IND-CCA secure, and a few years later Thai Duong and Juliano Rizzo turned that property into BEAST. Then there was CRIME, then Lucky13, and finally TLS MtE CBC had to be put to sleep.

One important thing to note however is that most (all?) of the TLS attacks rely on opening many thousands or millions of connections via scripting. Without this, these attacks would not be possible. A messaging system like telegram is not scriptable and hence, should not be exploitable in the same sorts of ways.

Of course, as you say, better solutions like Signal and OTR exist.

I'm really disappointed with the project management of Signal though, the shitstorm with F-Droid and Moxie's strange obsession with using 3rd party analytics software in privacy software, the fact they pulled socialist millionaires (zero knowlege proof based verifications) and left only automatic "let's trust the server" and QR code verification, the strong reliance upon phone numbers which still hasn't been broken even with the desktop release, etc... ChatSecure and similar might be a better option.

Are you here to discuss the cryptography of Telegram, or just to slag Signal?

> This is such a common flaw that Moxie Marlinspike, a co-author of TextSecure/Signal, which you should use in preference to Telegram, named it "the cryptographic doom principle".

He also wrote a good post explaining it:

http://www.thoughtcrime.org/blog/the-cryptographic-doom-prin...

> The easiest way to lose IND-CCA security is to fail to MAC your ciphertext

Or the easiest way to get IND-CCA is to add a MAC to your ciphertext 8)

Actually, it's not that your scheme magically gain IND-CCA when you add the MAC, it is that the attacker just lose the CCA attack model (he can't test random decryptions anymore).

Unless you fail to MAC in constant-time. Then you've just made it less convenient.

Does this only affect the standard Telegram chats or also "Secret Chats" as well?

My understanding is that the "secret chats" (which should be, but aren't, the default) use the same bulk encryption construction.