pgpfan:mdc
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
| pgpfan:mdc [2022/05/28 19:53] – Cryptography jargon b.walzer | pgpfan:mdc [2022/05/28 20:54] – [A Less Intuitive, More Technical Explanation] Awkward phrasing b.walzer | ||
|---|---|---|---|
| Line 13: | Line 13: | ||
| {{mdc1.svg}} | {{mdc1.svg}} | ||
| - | We create this by hashing the message. Then we append the hash to the end of the message. After that we encrypt everything; message and hash. To check for modification we hash he message and compare that hash to the hash appended to the message. | + | We create this by hashing the message. Then we append the hash to the end of the message. After that we encrypt everything; message and hash. To check for modification we hash the message and compare that hash to the hash appended to the message. |
| Let's consider the easiest situation for the attacker and assume they know the entire message. Then the attacker can hash that known message and will then know what the hash was before encryption. As a result they can modify the hash to any value they want by flipping bits as required. So the attacker can change the message to anything they want without restriction and can change the hash so that their changes would not be detected. If their target message is shorter than the original they can just generate the hash early and drop the extra part. So this is not entirely secure. | Let's consider the easiest situation for the attacker and assume they know the entire message. Then the attacker can hash that known message and will then know what the hash was before encryption. As a result they can modify the hash to any value they want by flipping bits as required. So the attacker can change the message to anything they want without restriction and can change the hash so that their changes would not be detected. If their target message is shorter than the original they can just generate the hash early and drop the extra part. So this is not entirely secure. | ||
| Line 41: | Line 41: | ||
| * The random data prefix is very well protected by the OpenPGP version of cipher feedback (OCFB). | * The random data prefix is very well protected by the OpenPGP version of cipher feedback (OCFB). | ||
| | | ||
| - | This might seem inelegant but it makes complete sense in an the OpenPGP context. This was preexisting in the OpenPGP standard: | + | This might seem inelegant but it makes complete sense in the OpenPGP context. This was preexisting in the OpenPGP standard: |
| * The OCFB block mode is the standard mode used in OpenPGP. | * The OCFB block mode is the standard mode used in OpenPGP. | ||
| Line 60: | Line 60: | ||
| =====A Less Intuitive, More Technical Explanation===== | =====A Less Intuitive, More Technical Explanation===== | ||
| - | OCFB-MDC is a case of hash then encrypt. The cipher block mode used is the modified version of cipher feedback used by OpenPGP (OCFB). The modification is | + | OCFB-MDC is a case of hash then encrypt. The cipher block mode is the modified version of cipher feedback used by OpenPGP (OCFB). The modification is |
| the addition of a prefix block consisting of random data. The traditional CFB initialization vector (IV) is replaced by the encryption of a block of zeros. | the addition of a prefix block consisting of random data. The traditional CFB initialization vector (IV) is replaced by the encryption of a block of zeros. | ||
| This serves to prevent an attacker from being able to get access to either the IV or the plaintext value of the random data prefix block. | This serves to prevent an attacker from being able to get access to either the IV or the plaintext value of the random data prefix block. | ||
pgpfan/mdc.txt · Last modified: 2023/12/11 13:30 by b.walzer