Hacker News Reader

Comment by tomfitz | Hacker News Reader

Snapchat use ECB as the cipher mode of operation: https://github.com/thebradbain/snapception/blob/781ebb13cd7e...

To see why this is a problem, see the ECB-encrypted Tux image on http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#...

Oops.

View on HN

To be fair, that demo only works on an uncompressed bitmap image with large areas of solid color. It relies on the fact that identical input blocks encrypt to identical outputs, leading to visible repeating patterns. In a format like JPEG, which has an entropy-coding stage and all kinds of internal headers, the chance of encountering two identical blocks in a file is miniscule.

Of course ECB is still a very bad choice, because there are plenty of other ways to attack it. But recovering Snapchat images without the key would not be nearly as trivial as that example might suggest.

I don't know a lot about the specifics of JPG file format, but... with a complex file format you can probably make some educated guesses about the content of some of the blocks and perhaps start building up a sort of dictionary... ?

Yeah, ECB is BAD.

To the extend that AES is a good random number generator, only if you have a complete dictionary of all blocks. Simply because a random number generator should produce independent output even if you only have a small perturbation in the input. That is, there should be no relation between a completely white block and an one where one of the pixels has a value of 0xfffeff.

Absolutely! There's no way I know to get at partial blocks where you have some knowledge, but even then you may have the start of some plaintext-leakage with the known-data and dictionary approach.

To protect in-flight data HTTPS encryption would be sufficient, since the attacker would have to MITM the connection and forge certificates instead of passively listening.

But once it reaches the end device it is impossible for snapshat to deliver on its promises of ephemeral messaging. To display the data the device needs to be able to decrypt it. If it can be decrypted it can be copied.

It's very much the same conceptual impossibility that DRM faces.

So in the end it doesn't really matter whether it's ECB or something better. It remains a DRM scheme.

Was this relevant to the comment you replied to?

Yes, the point is that whether they use ECB or not makes no difference and thus can't be considered an "Oops" in this use-case.

ROT13, AES-ECB or some state-of-the-art crypto, it's all the same if the end-device needs to have the key to decrypt it anyway.

Not just that, but because it's a fixed key, and it's now known, there was no forward security. If you've been in any way able to collect pictures but not decrypt them, now you can.

Reply on news.ycombinator.com