|
|
|
|
|
by tptacek
2666 days ago
|
|
You did not exploit a CBC padding oracle in CTR mode, because CTR mode isn't padded. Again: that is the point of CTR mode: to transform a block cipher (or, for that matter, a keyed hash function) into a stream cipher. GCM is built on top of CTR; CTR is literally in the name. Like CTR, GCM is a stream cipher mode. There is no GCM padding. The output of the code you pasted should be 26, 27, and 27, not 28 (as it is on my system). "test12" and "test13" have the same length, and consume the same amount of CTR keystream. |
|
This is sort of why I don't like tying my identity to any accounts on the internet and don't engage in academia. When you do, you have to dig in deep on your statements and then end up with meaningless ad-hominem attacks on identity rather than seeking truth to the discussion. This is increasingly happening all over the internet, too, so I might just drop off of it entirely and just go back to reading for my own sake.
> You did not exploit a CBC padding oracle in CTR mode, because CTR mode isn't padded.
Correct, I have never done that nor have I claimed to. I said the class focused on CBC padding oracles and I exploited CBC mode in that way. I also stated that I've used CTR mode before. These were two different statements. This is so far off-topic that I don't understand why you care.
> GCM is built on top of CTR; CTR is literally in the name. Like CTR, GCM is a stream cipher mode. There is no GCM padding.
You are literally responding to a comment where I show there is no padding and concede you are correct here.
> The output of the code you pasted should be 26, 27, and 27, not 28 (as it is on my system). "test12" and "test13" have the same length, and consume the same amount of CTR keystream.
It was supposed to be testbytes123, and I copied from an IPython window where I had typed both out. I apparently not only typed it in incorrectly the first time when entering it in and corrected it, but then copied and pasted the wrong line when going back to this window.
Look, I'm trying to get to the bottom of the original debate here, I don't really care too much about my copy paste errors or stating for a ninth time that my original comment was incorrect because it's been awhile since I went through these courses. I want to learn things, not have an ego fight. Let's move on.
The original topic being, why exactly is AES-GCM considered more secure than CBC by expert cryptographers?
I've been re-reading parts of Katz' book and I think I can come up with my interpretation, but I'm trying to find a section where he mentions this (because he comes very close in a few sections when discussing the classes of proofs themselves and also of his old-timey stories). I also think he could word it better and his reasoning might be different than my theory.
I think the point is that if you can choose the length of the attack, it doesn't matter if it's grouped into clusters of X-bits or not as long as the message is at least of a certain length (obviously encrypting the string "true" and "false" you'll be able to tell the difference if you know the context). If you can choose the length of the attack, then you'll most likely always be able to determine the length of various other encrypted information in the resulting ciphertext, it just becomes slightly more work.
So say I have X-bits of plaintext that I control of a plaintext that includes other text before being encrypted (HTTP as the example here). If it's padded, it might output Y-bits of ciphertext. If you then do (X+1)-bits of plaintext, you could again get Y-bits of ciphertext again. This can be perceived as an advantage, but if the attacker then pads the plaintext with zeroes at the beginning and incrementally passes it to the server, the (X+2)-bit, up until (X+Z)-bit output will eventually tick over to the next block, and then you have (Y+blocksize)-bit ciphertext. At that point, they can hang there at that specific plaintext length and then use that to perform the same length-based attack as without padding.
I'm going to keep digging because this question is really fascinating to me right now. Katz does have sections where he mentions fixed-length encryption mechanisms where the ciphertext is defined at a certain length, so I'm looking around there right now because I have a feeling he might probably somewhere state that any stream-cipher (which he includes CBC-mode as a stream cipher) is default less secure period. He might even have a proof somewhere on that.
The point of the padding in CBC mode is simply because it's necessary based on the way the plaintext moves into the encryption function. Padding oracles are dangerous because they exploit the type of padding, not because they exploit the length. They also do so in a way that allows you to decrypt entire blocks. IV-reuse can bump into a similar block border issue as I was describing above, too.
I will keep reading.