Possibility of Chosen Plaintext Attack (CPA) in real-world scenario?

In CPA, it is said that the adversaries get ciphertext for the choice of plaintext of adversaries through an encryption oracle. Is this a realistic assumption in real-world, in which the adversaries get ciphertext for the choice of their plaintexts? If so, please provide me with some example scenarios illustrating how adversaries obtain ciphertexts for their plaintexts?

7 Answers
7

Bruce Schneier foresaw your skepticism and directly answered this question in "Applied Cryptography":

Known-plaintext attacks and chosen-plaintext attacks are more common than you might think. It is not unheard-of for a cryptanalyst to get a plaintext message that has been encrypted or to bribe someone to encrypt a chosen message. You may not even have to bribe someone; if you give a message to an ambassador, you will probably find that it gets encrypted and sent back to his country for consideration. Many messages have standard beginnings and endings that might be known to the cryptanalyst. Encrypted source code is especially vulnerable because of the regular appearance of keywords: #define, struct, else, return. Encrypted executable code has the same kinds of problems: functions, loop structures, and so on. Known-plaintext attacks (and even chosen-plaintext attacks) were successfully used against both the Germans and the Japanese during World War II. David Kahn's books [794, 795, 796] have historical examples of these kinds of attacks.

Here are the referenced books:

It's not necessary that you encounter a situation like this in the real world to motivate the definition.
There are some weaker adversaries that you would like to rule out in your security model, and CPA-security usually would encompass them all.

Think for example of an encryption scheme which is intended to be used to encrypt one bit, like "yes" or "no".
In such scenario it is not so unreasonable to assume that an adversary can force some of the parties to encrypt messages of its choice! Specially if this response depends on some external behavior, potentially controlled (or partially controlled) by the adversary.

To be more concrete, think of a situation in which one observator will report to his headquarters whether or not enemy troops are moving (yes or no).
Clearly, by intercepting the secure channel and by moving the troops adequately, a CPA attack can be mounted (if I'm not wrong something like this did happen during the second world war... does someone have a reference?).

The attack here works because the distribution of the inputs can be altered by the adversary.
There are some other scenarios in which such correlation makes sense, and CPA security is there to provide security guarantees without knowing the internals of such correlation: By allowing the adversary to choose the messages at its own will, any possible attack by biasing the input distribution is ruled out.

In general, the goal of CPA security is to avoid the security of the scheme to be affected by a possibly malicious input distribution. We want security to rely on the distribution of the keys, not on the distribution of the inputs. Therefore, even if the inputs are somehow correlated to adversarial behavior, in a CPA-secure scheme nothing can be learned about a plaintext from a ciphertext.

Practical chosen-plaintext attacks have been discovered against modern cryptosystems like TLS/SSL. One noteworthy type of vulnerability can occur when a cryptosystem includes a compression step before encryption (which TLS used to do). This led to several well-known exploits such as CRIME and BREACH.

In CRIME, the adversary attacks a visitor of a HTTPS-secured website by inducing the victim's web browser to include text of the attacker's choice in requests made to the target website. By observing the length of an encrypted request, the attacker can then deduce whether other parts of the request matched the chosen plaintext: in case of a match the compression causes the request length to be slightly smaller than it would be otherwise. This allows the attacker to gain information about secrets included in the request, e.g. the victim's session token which may be sent as a cookie.

Juliano Rizzo, one of the researchers who found CRIME, describes it as follows:

[...] “Basically, the attacker is running [a] script in Evil.com. He forces the browser to open requests to Bank.com by, for example, adding tags with src pointing to Bank.com,” Rizzo said. “Each of those requests contains data from mixed sources.”
In these requests, attacker data and data produced by the browser is compressed and mixed together. Those requests can include the path, which the attacker controls, the browser’s headers, which are public, and the cookie, which should be secret.

“The problem is that compression combines all those sources together,” Rizzo added. “The attacker can sniff the packets and get the size of the requests that are sent. By changing the path, he could attempt to minimize the request size, i.e., when the file name matches the cookie.” [...]

A detailed description can be found in this question on security.SE.

In response to CRIME, the compression feature was deprecated in newer versions of TLS. However, attacks can still occur if the application protocol on top of TLS performs compression (e.g. HTTP gzip compression; SPDY; etc.). BREACH is an example of such a CRIME variant.

BEAST, an earlier attack by the same researchers, was another chosen-plaintext attack against TLS. It did not rely on an abuse of compression, but exploited a vulnerability in how CBC mode was implemented in block ciphers of TLS 1.0 and earlier.

There are some interesting examples in section 3.4.2 of Katz-Lindell book. Here is just one of them:

During World War II, the British placed mines at certain locations
and (intentionally) managed to let the Germans discover them. They
knew that the Germans would encrypt the locations and send back to the headquarters. These encrypted messages were used by cryptanalysts at Bletchley Park to break the Enigma machine.

The lead up to the Battle of Midway also involved a chosen plaintext attack. The Americans had mostly broken the Japanese code JN-25b, and knew the Japanese were attacking "AF". They guessed that "AF" was Midway, but to be sure they had Midway send a cleartext message that their fresh water system was broken, and soon picked up a Japanese message "AF was short on water".

Another scenario: a disk encryption system where the attacker can let the system store chosen files in a known location (like a Downloads folder), and can observe the cipher text later.

Another WW2 example. German U-boats always started their encrypted transmissions with a weather report in a standard format which was revealed when the British captured a copy of the weather codebook. If the British knew what the weather was like at the time and place of the transmission, then they knew what the plaintext must be. (The U-boats also disengaged one rotor of their four-rotor Enigma machines for the weather report, which was even more stupid but is not relevant here.)

Required, but never shown

Required, but never shown

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.