3

Lately I came across of release of unverified plaintext. I was told that this is a bad thing, but I don't really get why. Isn't unverified plaintext released just nonsense? How can this be attacked in the context of authenticated encryption?

Maarten Bodewes
  • 92,551
  • 13
  • 161
  • 313
Digimon Kaiser
  • 79
  • 2
  • What does it mean for plaintext to be released? And what is "unverified plaintext?" Forgeries? Any plaintext not yet authenticated? Are you talking about decrypting a message and making it public if the mac doesn't match? If so, then just take a ciphertext from a legitimate sender with the correct authentication tag and change the tag to any other value. There goes all message secrecy. – Future Security Jun 13 '18 at 00:44

2 Answers2

4

If you don't care about the authenticity of the plaintext, why are you listening for it in the first place? You could make up plaintext on the spot with your ears plugged up and it would be just as good!

Here's the traditional example: You are a general. You receive a message that says, Attack at dawn!. Since it is late at night already, your cryptographer on staff decided to rush it to you before verifying the authenticator on it. Alas, it was a forgery. The secret message actually sent by your fellow general was Attack at dusk!. That message, encrypted by a one-time pad, was intercepted in transit, and its ciphertext xored with the Attack at dawn! xor Attack at dusk!.

That is:

  • the original plaintext $P$ was Attack at dusk!;
  • the modified plaintext $P'$ is Attack at dawn!;
  • the original ciphertext was $C = P \oplus K$ where $K$ is the one-time pad;
  • the modified ciphertext is \begin{align*} C' &= P' \oplus K \\ &= 0 \oplus P' \oplus K \\ &= P \oplus P \oplus P' \oplus K \\ &= P \oplus P' \oplus P \oplus K \\ &= P \oplus P' \oplus C. \end{align*}

This may sound contrived and goofy, but mistakes like this still happen today—and much faster, because your cryptographer on staff is actually a computer making millions of decisions every second and leaking the content of your encrypted email to an attacker.

‘But, but,’ you say, ‘you contrived that example to make it really easy for the attacker to modify the message, by using xor. Surely the well-known mode of operation like CBC thwart this?’ It does not. In fact the additional unnecessary complexity of CBC enables other attacks. A one-time pad with a one-time authenticator guarantees secrecy and negligible forgery probabilities; CBC guarantees nothing whatsoever about forgery—every string of blocks is a valid ciphertext in CBC, so the cryptography can do nothing to distinguish valid messages from invalid messages.

To make the one-time pad and authenticator practical, generating the one-time pad and the one-time authenticator key from a short secret by a pseudorandom function like ChaCha or AES-CTR is widely accepted to be a good method that nobody is likely to break. Better yet, just use NaCl crypto_secretbox_xsalsa20poly1305 when you and your peer share a secret key and you want to exchange secret messages on a potentially compromised channel. (In a sequential conversation, use message sequence numbers as the nonce; in a nonsequential conversation, pick the nonce uniformly at random and affix it to the message.)

Unauthenticated data is pure evil—don't touch it!

Squeamish Ossifrage
  • 48,392
  • 3
  • 116
  • 223
  • Just one more question: You also wrote about CBC and the padding Oracle. But what if we use CTR with release of unverified plaintext? – Digimon Kaiser Jun 12 '18 at 07:42
  • 1
    CTR creates a stream cipher from a block cipher. And a stream cipher creates a key stream just like the one used for an OTP. So the attack on CTR is exactly the same as the one in the example with "Attack at dusk/dawn". – Maarten Bodewes Jun 12 '18 at 12:50
  • It might be that I missunderstood something, but with the OTP Attack above we still cannot create a valid Tag, can we? I mean, if we have some PRF which computes under a different key a Tag for authentication? – Digimon Kaiser Jun 13 '18 at 07:36
  • @DigimonKaiser Correct. That's what makes it authenticated. The problem arises if you reveal plaintext without (or before) checking the tag. – Squeamish Ossifrage Jun 29 '18 at 20:02
  • @SqueamishOssifrage But doesn't your example require the attacker to know the original plaintext $P$? I'd assume that the enemy general would only know $P'$ and $C$ – ManRow Dec 09 '22 at 23:05
  • @SqueamishOssifrage Edit: just realized you never mentioned there being an "enemy general", so ultimately you could have just instead been referring to some sort of double agent or spy that had the access to the original plaintext $P$... – ManRow Dec 09 '22 at 23:07
1

Isn't unverified plaintext released just nonsense?

You're looking at it from a human perspective, and assuming that gibberish is harmless because there's a human in the loop that would spot it. But decryption is performed by computers, which often perform programmatic actions based on the decrypted data, blind to the fact that their code's preconditions have been violated by an unauthentic ciphertext.

One very concrete example is that the recent Efail vulnerability would have been impossible if GnuPG did not release unverified plaintext. Because it does, the email clients then displayed the message designed to contain offending HTML, and as part of rendering this made an HTTP request to an URL that contains the plaintext. And more generally, any computer program that decrypts data and acts on it automatically without human supervision could potentially be exploitable through ciphertext malleability attacks.

Then there's also the fact that some authenticated ciphers are vulnerable to cryptanalytic attacks if the adversary sees unverified plaintexts or their tags, but my point is that even if we have a cipher that's not weak that way, releasing unverified plaintexts is still dangerous.

Luis Casillas
  • 14,468
  • 2
  • 31
  • 53