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.

  • 1
    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
up vote 5 down vote accepted

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
  • 1
    @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
  • 1
    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).

Another advantage is that your payload length is not restricted as in the pure RSA case.

This scheme provides payload confidentiality (an attacker without server private key can not read the payload) and integrity (the payload is received exactly as intended by the client or is dropped by the server as invalid), but does not provide any sender authenticity (anyone knowing the server public key can generate valid messages with arbitrary payloads).

Sender authenticity might be addressed by signing the payloads.

Desclaimer: I am no crypto expert, so please do validate my thoughts.

  • 1
    That's insecure because the key could be easily replaced by an attacker! – t0b0 Aug 16 '15 at 16:33
  • @t0b0 That an attacker can replace the key and message is always the case for asymmetric encryption. You need to add some kind of sender authentication, such as a signature or DH+MAC if you want to prevent that. The concept vlp describes is known as hybrid-encryption and sound, as long as you take the pitfalls otus mentioned into account. – CodesInChaos Aug 16 '15 at 17:57
  • @t0b0 You are right about the easy message forgery. It all depends on the desired security properties. If message confidentiality & integrity is all he needs, this should make it (i.e. anonymous.bulletin board -- you post a text+timeToPublish to the server and the server publishes your text accordingly). By using the key encapsulation otus suggests this scheme should be padding oracle resistant. – vlp Aug 16 '15 at 21:18
  • @vlp The point is that your proposed solution does not provide integrity, so don't claim it. – t0b0 Aug 16 '15 at 22:32
  • 1
    @t0b0 I am here to learn. In my opinion the server receives the message payload as it was sent by the client or it drops it as invalid. And I call that property 'integrity'. Do you know a way to tamper the payload without the server's private key (when key encapsulation and AE is in place)? – vlp Aug 16 '15 at 23:19

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.