7 ms·

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

by tomfitz 12y ago

Snapchat use ECB as the cipher mode of operation: https://github.com/thebradbain/snapception/blob/781ebb13cd7ee75cb56c744a94fa3945e764dd7a/snapception/decrypt_snap.rb#L15 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#Electronic_codebook_.28ECB.29 http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#... Oops.

teraflop 12y ago
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.
- Nursie 12y ago
  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.
  - yk 12y ago
    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.
    - Nursie 12y ago
      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.
pslam 12y ago
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.
the8472 12y ago
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.
- waxjar 12y ago
  Was this relevant to the comment you replied to?
  - the8472 12y ago
    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.

by tomfitz 12y ago

teraflop 12y ago

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.

Nursie 12y ago
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.
- yk 12y ago
  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.
  - Nursie 12y ago
    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.

pslam 12y ago

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.

the8472 12y ago

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.

waxjar 12y ago
Was this relevant to the comment you replied to?
- the8472 12y ago
  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.