
Padding Oracles: An Animated Primer - dpindur
https://dylanpindur.com/blog/padding-oracles-an-animated-primer/
======
TwoNineFive
If you want to see a good real-world case, look at OpenVPN and it's use of
compression which allowed an oracle attack: [https://openvpn.net/security-
advisory/the-voracle-attack-vul...](https://openvpn.net/security-advisory/the-
voracle-attack-vulnerability/)

------
awinter-py
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

~~~
tialaramex
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
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.

