A method called cipher feedback (CFB) is used in OpenPGP to prevent data leakage and make modification more difficult. It seems appropriate here to discuss the advantages of this method.

OpenPGP, like most other systems, uses a something called a block cipher to encrypt things. You start with a fixed block of data (usually 16 bytes), run it through the block cipher encryption function, and end up with an encrypted block of data of the same length. To get back the original data you run the encrypted block through the block cipher decryption function.

It is very possible that you have more than 16 bytes of data to encrypt. You could just apply the encryption function in sequence to each block until you run out of data¹⁾. For decryption you would just apply the decryption function to each block in sequence. This method, although simple, has some weaknesses.

If an attacker has some idea what is encrypted in the blocks they might be able to shuffle/duplicate/delete them in a way that might mislead you after they are decrypted. Because all the blocks with the same data will encrypt to the same value, an attacker might be able to see patterns that might give them some idea of what that data is.

Cipher Feedback (CFB) (the thing that OpenPGP does) is a method that overcomes these shortcomings. Instead of encrypting the block you instead encrypt the last encrypted value, add the block in, and use this as the next encrypted value. Very simple.

Patterns in the encrypted output are eliminated. Since CFB uses the popular technique of adding in the unencrypted block to make the encrypted block it is possible to flip bits in the eventual decrypted output. CFB imposes a cost to such modification however. Even a single bit flipped in a block will result in the entire next block being converted to random garbage. Attempts to shuffle/duplicate/delete the blocks will cause such random garbage at the edges of the modified areas. This is what an attempt to modify the first, third and seventh blocks would look like:

Attacks must work around the random garbage and the corresponding lost data. In a case where the recipient of a modified message sees the result of the CFB protection the resulting textual gibberish makes it intuitively obvious that some sort of modification has occurred. An attack on some automated subsystem would be at peril of having the subsystem choke on the random garbage. CFB adds significant difficulty to attacks that involve modification of the encrypted material.

CFB has some desirable secondary characteristics:

CFB uses the encryption function for both encryption and decryption²⁾. That simplifies things somewhat.

CFB is self synchronizing. Corrupt or missing blocks will cause the next block to be random garbage but the following and subsequent data will be decrypted properly. This is consistent with the principle that encryption should not prevent access to good data.

CFB requires no extra complication when the data does not completely fill the last block. It just works.

CFB decryption can be done in parallel. You can take separate sections of an encrypted message/file and decrypt them independently.

The protection provided by CFB is intrinsic. It becomes an essential part of the protocol. If it is implemented incorrectly it will not interoperate with correct implementations. Contrast this with schemes that only check for modification and do nothing to prevent it in the first place³⁾.

OpenPGP has multiple implementations in common use. So a user of OpenPGP can be sure of CFB protection. The user of a system that merely checks for modification can not be entirely sure that the check is currently protective. Message modification is very rare. A broken check might not be noticed for a long time.

The EFAIL vulnerability is an excellent example of this. It involved the modification of OpenPGP formatted messages. It turned out that some email clients were sending these modified messages to an an interpreter that leaked data (HTML) after decrypting them. The clients in question were ignoring the warning from the OpenPGP provided modification detection check (MDC). CFB contributed significantly to the difficulty and impracticality of the attack.