Differences

This shows you the differences between two versions of the page.

--- pgpfan:cipherfeedback [2021/12/17 12:55] – Failed to show what was being made into a TLA. b.walzer
+++ pgpfan:cipherfeedback [2022/05/09 17:05] (current) – Clearer b.walzer
@@ Line 11: / Line 11: @@
 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 block to make the encrypted value it is possible to flip bits in the eventual unencrypted output. CFB imposes a cost to such modification however. Even a single bit flipped in a block will result in the entire next block coming out as random garbage. Attempts to shuffle/duplicate/delete the blocks will cause such random garbage at the edges of the modified areas. Attacks must work around this garbage and the corresponding lost data. As a result such attacks are significantly more difficult.
+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:
+{{cfb_damage.svg}}
+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:
@@ Line 17: / Line 22: @@
 CFB uses the encryption function for both encryption and decryption(([[wp>Block_cipher_mode_of_operation#Full-block_CFB|Full Block CFB]])). 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 destroy access to good data.
+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((The popular [[wp>Block_cipher_mode_of_operation#Counter_(CTR)|counter mode]] allows any bit in the message/file to be flipped at no cost. It is entirely dependent on some sort of check to detect such bit modifications.)).
@@ Line 25: / Line 32: @@
 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 [[https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-poddebniak.pdf|EFAIL]] vunerability 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 OpenPGP provided modification check ([[pgpfan:mdc)|MDC]]). CFB contributed significantly to the difficulty and impracticality of the attack.
+The [[https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-poddebniak.pdf|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 ([[pgpfan:mdc)|MDC]]). CFB contributed significantly to the difficulty and impracticality of the attack.