Are there actual consequences of padding oracle attacks?

Question

I am writing a program that encrypts data in Python and heard about padding oracle attacks, but I think they are overrated (I mean, what are the real-world uses?) even for the old implementations that are vulnerable (the ones that tell if padding is right or wrong like SSLv3).

Because:

1. If all I need are two ciphertexts $c(n-1)$, $c(n)$ which are the last two encrypted messages blocks, and a server to tell me if the padding of decrypted $c(n)$is correct or whatever, doesn't that mean that the server just decrypts whatever you send to it (I mean, just send the whole encrypted message as you received it and read the output). I mean, this is the server bug that it doesn't take a key in the first place and check if it's correct.
2. Let's assume that all we have to do is send those two cipher messages to know and decrypt the last block (the padding block). This only works since the padding plaintext is known or at least not random or whatever reason.

But what about, say, c2 and c3 which are in the middle of the whole message? We know c3 and c2, but we don't know and we will never know either p3 or p2 (plaintext), nor the intermediate state IS3; i.e. we can't XOR c2 with is3 to obtain p3, so this attack I think only allow us to decrypt the padding block with the only new thing we actually knew is an intermediate state of padding block.

I am asking to know if this attack is just a one with no real-world implications and no real data decryption capabilities (actual data).

Answer 1

I mean this is the server bug that it doesn't take a key in the first place and check if it's correct :)

What do you mean with that? The key must be the right one, and the padding oracle attacks actually change the ciphertext encrypted with that key on the other side to perform the attack.

but what about say c2, c3 which are in the middle of whole message, we know c3 and c2 but we dont know and we will never know either p3(plaintext of course) nor intermediate state IS3

No, a padding oracle attack is able to completely decrypt a message. This is precisely because the XOR influences the next block.

Note that padding oracle attacks are just one form of plaintext oracle attack. For instance, you can also perform plaintext oracle attacks on XML-enc, even without using the padding itself.

I am asking to know if this attack is just a one with no real world implications and no real data decryption capabilities(actual data) .

Yes, that's utterly and completely wrong. A padding oracle attack can decrypt the whole message using 128 tries per byte, and other plaintext oracles can actually be even more effective.

Besides that, having the receiving end accept a changed plaintext is possibly as dangerous as loosing confidentiality. For that reason you should use authenticated encryption - or rather a protocol that utilizes authenticated encryption instead of unauthenticated CBC.

Answer 2

I am asking to know if this attack is just a one with no real world implications and no real data decryption capabilities(actual data) .

The Lucky Thirteen attack is a real-world attack against TLS. It was a serious attack for the then current versions of the TLS protocol (TLS 1.0 at the time — TLS 1.1 and 1.2 existed but had very little adoption). So no, padding oracle attacks absolutely do work in the real world.

(the ones that tell if padding is right or wrong like sslv3).

Lucky Thirteen affects versions up to TLS 1.2, which is the version used for the majority of secure communications today. It only affects cipher suites that use CBC, which are deprecated precisely because of this attack, but most endpoints still allow it, even if they'll prefer AEAD ciphersuites. Many but not all popular TLS implementations have code that prevents Lucky Thirteen attack (at the expense of performance). So no, padding oracle attacks are relevant to protocols that are still in widespread use.

I am writing a program that encrypt data in python and heard about padding oracle attacks but i think they are overrated

Well, it's true that you shouldn't worry about padding oracle attacks. But the reason you shouldn't worry is that since they're well-known, we know how to defend against them: don't use padding. And no encryption modern mode uses padding. Just use any common AEAD mode, such as GCM, CCM or ChaCha20+Poly1305. Or even better, use a high-level library such as NaCl/libsodium (PyNaCl in Python): if you're typing the letters A-E-S into your code, you're doing it wrong.