3 ms·

possibly stupid question: how is the penguin jpeg still square after encryption? wouldn't compression mean that even with a weak cipher, jpeg segments will be o

possibly stupid question: how is the penguin jpeg still square after encryption? wouldn't compression mean that even with a weak cipher, jpeg segments will be of variable size and therefore take up varying # of blocks? it seems like this example relies on the image being a bitmap without even run-length compression

upofadown 6y ago
>it seems like this example relies on the image being a bitmap without even run-length compression Correct. This isn't an example of any sort of practical attack. It is just a visual way to show that you can leak information when each unique block encrypts to the same value.
tialaramex 6y ago
The other comment explains that in fact a JPEG is not what's actually used in the Tux ECB demo, yes, it's a specific type of uncompressed bitmap data that was easiest to do the demo on. However, since you brought it up - JPEG data probably doesn't work how you think it does if you're surprised a JPEG is "still square". In fact if you smash random bits near the start (as would happen if you just tried to feed an AES-ECB encrypted JPEG file through a decoder) it's just not a valid JPEG any more. But if you were to leave a valid header, the images are damaged in a predictable way because of how JPEG compression works. There aren't "variable size segments" instead JPEG cuts everything into blocks made of 64 pixels (8 by 8) and then it handles each of these blocks separately, in effect the "lossy compression" of JPEG consists of throwing away some of the information within each such block.
- awinter-py 6y ago
  Ah, didn't know JPEG blocks were consistently 8x8. But I'm assuming storage size of each block is variable-length? BMP wouldn't be decodable either; header gets mangled, right? This is a some kind of rendering of the cipher text. But in the 'block cipher on simple bitmap' case, the blocks map well to pixels; with any compressed format, that wouldn't be true.

upofadown 6y ago

>it seems like this example relies on the image being a bitmap without even run-length compression Correct. This isn't an example of any sort of practical attack. It is just a visual way to show that you can leak information when each unique block encrypts to the same value.

tialaramex 6y ago

The other comment explains that in fact a JPEG is not what's actually used in the Tux ECB demo, yes, it's a specific type of uncompressed bitmap data that was easiest to do the demo on. However, since you brought it up - JPEG data probably doesn't work how you think it does if you're surprised a JPEG is "still square". In fact if you smash random bits near the start (as would happen if you just tried to feed an AES-ECB encrypted JPEG file through a decoder) it's just not a valid JPEG any more. But if you were to leave a valid header, the images are damaged in a predictable way because of how JPEG compression works. There aren't "variable size segments" instead JPEG cuts everything into blocks made of 64 pixels (8 by 8) and then it handles each of these blocks separately, in effect the "lossy compression" of JPEG consists of throwing away some of the information within each such block.

awinter-py 6y ago
Ah, didn't know JPEG blocks were consistently 8x8. But I'm assuming storage size of each block is variable-length? BMP wouldn't be decodable either; header gets mangled, right? This is a some kind of rendering of the cipher text. But in the 'block cipher on simple bitmap' case, the blocks map well to pixels; with any compressed format, that wouldn't be true.