Is this approach able to protect against padding oracle attacks?

Question

I know that a protection against the padding oracle attack is to encrypt-then-mac. This is to avoid trying to decrypt a modified ciphertext, and leak information about padding errors.

Suppose that we have a content which is signed, and then encrypted. For decryption and signature control, this content is processed in the following manner:

• decrypt the content without telling if the padding is correct on not.
• check the signature on the decrypted content and return an error if it is incorrect, which should be the case if the ciphertext was modified.

Is this treatment correct when wanting to avoid PO attacks (or any other chosen ciphertext attacks)?

To be more precise, the scenario would be:

• the content is signed with an asymmetric key (say a RSA-PSS signature),
• it's then encrypted with a symmetric algo (say AES-256-CBC), with a random key and a random IV,
• the symmetric key is encrypted with another asymmetric key (say a RSA-OAEP encryption),
• the ciphertext, the encrypted symmetric key and the IV are then transmitted to a receiver process.
• the receiver process decrypts the symmetric key without telling if there is a padding error (OAEP padding)
• it then decrypts the ciphertext with the (possibly badly decrypted) symmetric key without telling if there is a padding error (AES-256-CBC padding)
• it then checks the signature on the (possibly badly decrypted, but good sized) content and returns an error if it is incorrect, rejecting the received content.

Answer 1

You have to differentiate between it being theoretically OK and practically. Without fully checking, I can say that such an approach may be possible to fully prove. However, practically, it is almost impossible to implement it. Specifically, you have to be able to make it impossible to differentiate between an error due to the symmetric decryption or the signature. However, this is really hard to do (actually, pretty much impossible). The reason is that you need to make it time-independent. But, if you have a padding error, you don't even know how long the message is to verify. The Lucky13 attack on TLS worked exactly because code that was written to be time-independent turned out to not truly be so in certain cases. So, I would never do such a thing.

A huge number of SSL/TLS weaknesses are due to doing MAC-then-encrypt, so don't do this. GCM is so fast today on Intel processors that there's no reason not to use (just make sure you always have a different nonce).

Answer 2

the receiver process decrypts the symetric key without telling if there is a padding error (OAEP padding)

The idea of OAEP padding is that you can check the correctness of the padding without being vulnerable to a padding Oracle attack. This is called "all-or-nothing" security. You could however replace the wrapped symmetric key with a previously wrapped symmetric key.

it then decrypts the ciphertext with the (possibly badly decrypted) symmetric key without telling if there is a padding error (AES-256-CBC padding)

Lets assume here that we get a previously wrapped symmetric key (as a wrong decrypt should not be possible).

In that case the padding likely fails and you're vulnerable against padding oracle attacks and possibly other plaintext oracle attacks. Those are tricky to avoid. For instance, to know the size of the resulting plaintext, you'd still need to unpad. Now the padding could be placed on a memory page boundary, leading to a timing attack.

it then checks the signature on the (possibly badly decrypted, but good sized) content and returns an error if it is incorrect, rejecting the received content.

Too little, too late. You'd still need some way of determining where the message and the signature are located. That's enough for plaintext oracle attacks. Besides, if anybody would change the encoding scheme you would be in trouble, even if you were not before.

As Yehuda already indicated, there are very few reasons not to use an authenticated cipher. You've been warned.