2

When I was reading Botan document, I came across the following note:

During decryption, finish will throw an instance of Integrity_Failure if the MAC does not validate. If this occurs, all plaintext previously output via calls to update must be destroyed and not used in any way that an attacker could observe the effects of.

One simply way to assure this could never happen is to never call update, and instead always marshall the entire message into a single buffer and call finish on it when decrypting.

Since this situation appears in the decryption, does that mean AEAD mode is insecure if the attacker have access to the files?

Or is there something I misunderstood?

Thanks in advance.

Community
  • 1
  • 1
Arolia
  • 511
  • 2
  • 6
  • 12
  • What do you mean with "this situation appears in the decryption"? What situation are uncertain of? – Maarten Bodewes Nov 09 '17 at 10:20
  • @MaartenBodewes As the document says, we should prevent the attacker from observing the plaintext previously output during decryption. So can an attacker simulate this decryption process and gain some information? – Arolia Nov 09 '17 at 13:10
  • No, it did not say that. If the validation fails then the plaintext should "not used in any way that an attacker could observe the effects of". That is, if you take action on malformed data the attacker might learn something as a result - what the attacker gets out of the situation entirely depends on the application. Just make sure the integrity holds before looking at the decrypted data, the fact that the API yields data prior to integrity checking is worrisome to begin with, but I get that streaming uses sometimes need this. – Thomas M. DuBuisson Nov 09 '17 at 15:59
  • 1
    In other words: Don't start sending data to a parser / deserializer, et cetera until you've verified the integrity (in AEAD: finished decrypting with no errors). Ideally you wouldn't let it buffer to file, either, since that might be observable; but if you need to for RAM limitation reasons make sure no one else can see it, and burn it with fire if something goes wrong. – bartonjs Nov 09 '17 at 17:31
  • Very succinct answers. I have misunderstood what it means. Thanks – Arolia Nov 10 '17 at 01:10

1 Answers1

2

The point of this warning is that you cannot trust any information before you've validated it. Note that the underlying mode of AEAD ciphers is usually CTR mode (other modes are similarly affected). So an attacker can for instance introduce errors in the ciphertext which translate into errors in the plaintext at the same location. Most AEAD ciphers use CTR mode underneath, so the attacker can flip specific bits of the plaintext that way.

An attacker can for instance learn about the plaintext by watching for the specific errors to occur when the - now invalid - data is processed. This is what the warning is about: you first need to establish the integrity and authenticity of the decrypted data before processing it.

Of course, this usually means caching the data until it is validated. For that reason it makes more sense to first create a buffer and load it with the ciphertext. If you have a good API you could overwrite it with the plaintext so you don't have to allocate the storage space twice.

You could still store the plaintext on disk of course, as long as you make sure to remove access to the data if the tag is not valid. For instance, you could store the data in a temporary file and then rename it to the right file name after verifying the tag.

That all said, no, the AEAD mode is more secure than any other, non-authenticated mode of operation, as you can verify message integrity and authenticity. But you can still use the cipher incorrectly, and that's what this is all about.

Maarten Bodewes
  • 90,524
  • 13
  • 150
  • 263