2

When the last n bytes of the plaintext are themselves suitably random, but predictably repeat m times in the same message - how bad is that? I'm convinced it is detrimental, but I am uncertain how detrimental exactly.

Edit: assume a Padding Oracle to be available.

NB: I'm not asking about the same overall plaintext sent multiple times.

I was looking into several know attacks, but couldn't come up with a calculation or estimation so far. I'm looking for pointers to dig deeper into the general analysis of this situation.

(If you must have an example, let's take n=8, m=3, and RSA, but I'd rather discuss this in general - probing the foundations, not a specific case.)

foo
  • 144
  • 6
  • 6
    If your encryption scheme is secure, it does not matter at all. – Maeher Dec 13 '22 at 05:43
  • That's a comforting blanket (statement), but I'm not convinced yet. Thinking of padding oracle attacks - isn't there a risk from this direction; and if not, why? – foo Dec 13 '22 at 15:51
  • 1
    One of the most fundamental properties required of cryptosystems is termed IND-CPA. Intuitively it ensures that, even if an adversary gets to freely choose two plaintexts, they are unable to subsequently differentiate between encryptions of the two. See this answer for the formalism. This also covers any weaker knowledge about the plaintext, such as when an adversary is aware of repeated patterns in the plaintext. – Morrolan Dec 13 '22 at 16:03
  • 1
    Regarding your edit - there is the extended formalism where the adversary is also assumed to be able to submit (mostly) arbitrary ciphertext to a decryption oracle. This happens to cover what a real-world padding oracle might expose (ie partial decryption information, such as whether it's a valid ciphertext at all). For this case there exists a (stronger) set of properties, termed IND-CCA, which ensure security in the presence of such an adversary. For details, see the same question as above. – Morrolan Dec 13 '22 at 16:09

1 Answers1

3

Padding oracles are relatively specific to a padding mode to be used. What you seem to be talking about is a specific plaintext oracle; a padding oracle can be seen as a special form of plaintext oracle. Such oracles can always be present if the receiver handles unauthenticated ciphertext. This is why the current focus is to use authenticated ciphers.

When we talk about padding oracles they are generally related to modes of operation such as CBC (or ECB, but yeah) and a padding scheme that extends the plaintext with padding bytes. Plaintext oracles may however be present for any mode of operation that doesn't provide message integrity.

Note that plaintext oracles are not limited to repeated characters; they are about known plaintext. If repeated messages from an adversary are allowed to be received, and the receiver handles the plaintext then an adversary may learn about the message from any leak related to the contents of the message.

The easiest way to avoid oracles is to use a transport layer protocol that uses an AEAD cipher (or at least a correctly applied authentication code such a tag generated by HMAC). Within transport security the session keys protect the messages, and if an attacker changes any protected message then the communication is shut down and a new (authenticated) session needs to be setup.

This is why cryptographers generally recommend TLS or SSH to developers. Creating a good transport layer is hard, and protection against plaintext oracles is only one reason why it is hard.

For asymmetric encryption it should be assumed that the attacker can send any message. This is because an attacker is assumed to have the public key used for encryption. The sender needs to sign a ciphertext to avoid oracle attacks for asymmetric encryption schemes.

Note that different padding modes of RSA can also be attacked if an oracle exists. Correct implementations of RSA decryption should not be vulnerable against padding oracle attacks though.

Maarten Bodewes
  • 92,551
  • 13
  • 161
  • 313