# How to verify the integrity of RSA encrypted messages?

I need to encrypt messages using PublicKeyCrypto and send it to the server, where the message should be decrypted. I'm aware of the Padding Oracle Attack and want to apply a server side integrity check of the incoming cipher messages. In AES there is the so called CCM mode, which performs the integrity checks implicitely. Is there something else for RSA decryption?

I'm using the 'javax.crypto.Cipher' library.

• OAEP should do what you need. – SEJPM Aug 15 '15 at 21:20
• You may be interested to take a look at my scheme of doing RSA encryption (without additional symmetric encryption algorithm) of messages with integrity check and sender's signature, see Example 3S in s13.zetaboards.com/Crypto/topic/7234475/1/ – Mok-Kong Shen Oct 29 '16 at 8:33

With pure asymmetric encryption there is no way to ensure integrity and authenticity, since anyone who knows your public key can encrypt any message for you. For that you would need either a symmetric key to use for a MAC (in which case you could use it/derivatives for symmetric encryption too) or a signature from the sender. And in the latter case the advice is to sign-then-encrypt, which doesn't help with any padding concerns.

There's no simple way to avoid leaking information through a padding attack, like with encrypt-then-MAC for symmetric encryption, if the padding algorithm is vulnerable to one. Instead, your implementation should not leak information about whether the padding is correct. OAEP is more resistant than older padding algorithms, but even it must be correctly implemented.

However, since you are using a high level cryptographic library, the low level details are not something you should have to worry about. The writers of that library should have taken care of those. Just choose the correct algorithm, i.e. OAEP. (I don't know details about any Java libraries' security record, though.)

• Thx for your reply. Would the integrity check work if the encrypted message is additionlally additionally encrypted (signed) with the senders (client) private key. So the receiver (server) would first need to decrypt the cipher with the clients public key. In case of an Padding Oracle Attack the first cipher could be determined but nothe plaintext message. Ist that correct? – My-Name-Is Aug 16 '15 at 9:37
• @My-Name-Is, yes with encrypt-then-sign only the padding of the signature algorithm could likely be attacked, if that's what you mean. You should avoid the terms encrypt/decrypt when discussing signature algorithms, however. – otus Aug 16 '15 at 10:33
• Pretty please with sugar on top, don't advice to use library defaults for cryptographic algorithms, especially not where Java is concerned. – Maarten Bodewes Aug 16 '15 at 10:42
• @MaartenBodewes, I didn't mean going with defaults and it's certainly a bad idea if that's the case. Edited to clarify, though I'm now hesitant to suggest even trusting the implementation. – otus Aug 16 '15 at 11:15
• The Java crypto library is pretty well designed. I haven't reviewed all the source code, but it certainly could be worse and I heard the testing is pretty extensive (if not open sourced). But Java is not that young anymore, so it does have ECB/PKCS5Padding (for symmetric ciphers) and PKCS1Padding (for RSA) as default. – Maarten Bodewes Aug 16 '15 at 20:20

You can use the RSA key encapsulation to establish a random symmetric key. Then (in the same protocol message) use this key to protect the data payload (i.e. using some AE/AEAD mode you mentioned).

The RSA key encapsulation should be Padding Oracle Attack resistant (as it does not use any padding).