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/17 11:12] – Forgot length. b.walzer | pgpfan:mdc [2023/12/11 12:56] – [A Less Intuitive, More Technical Explanation] Structure b.walzer | ||
---|---|---|---|
Line 3: | Line 3: | ||
I once worked for a company that had a strange and intriguing dilemma. They had a popular Product. Marketing determined that the popularity was due to the fact that the Product lasted significantly longer than competing products. No one in the company had the faintest idea why that was the case. The design did not differ in any obvious way from the design used by the competition. While I was there, an engineering project was initiated with the hope of understanding why the Product was better. I left the company before any definite result. For all I know the mystery still remains. | I once worked for a company that had a strange and intriguing dilemma. They had a popular Product. Marketing determined that the popularity was due to the fact that the Product lasted significantly longer than competing products. No one in the company had the faintest idea why that was the case. The design did not differ in any obvious way from the design used by the competition. While I was there, an engineering project was initiated with the hope of understanding why the Product was better. I left the company before any definite result. For all I know the mystery still remains. | ||
- | The situation with the OpenPGP modification detection code (MDC) very much reminds me of the story of the Product. Legend has it that the MDC was created as a kind of an afterthought. It works very well but it is not obvious why it does. I have never seen an inclusive explanation. Here I will attempt to produce such an explanation. | + | The situation with the OpenPGP modification detection code (MDC) very much reminds me of the story of the Product. Legend has it that the MDC was created as a kind of an afterthought((Since I first wrote this, I have come to believe that this is //just// a legend. The principles that make the MDC work were known at the time of its design. See the [[pgpfan: |
- | When used for something like email, the messages are authenticated directly with a signature. So the MDC is not relevant in the most common use case. So the MDC is not that important. It would still simplify things and eliminate much pointless discussion if the MDC could in fact be shown as strong. It would eliminate having to go through the more obscure uses of OpenPGP to determine how applicable the MDC was to each. | + | When OpenPGP is used for something like email, the messages are authenticated directly with a signature. So the MDC is not relevant in the most common use case. So the MDC is not that important. It would still simplify things and eliminate much pointless discussion if the MDC could in fact be shown as strong. It would eliminate having to go through the more obscure uses of OpenPGP to determine how applicable the MDC was to each. |
If you were to encrypt, say, a message text, an attacker would have no way to determine what was said in that message just by looking at the encrypted result. That, after all, is the whole point of encrypting it in the first place. An attacker might still be able to make changes to the text if they can get access to it along the way. If they know what text is encrypted they might, by duplicating, | If you were to encrypt, say, a message text, an attacker would have no way to determine what was said in that message just by looking at the encrypted result. That, after all, is the whole point of encrypting it in the first place. An attacker might still be able to make changes to the text if they can get access to it along the way. If they know what text is encrypted they might, by duplicating, | ||
- | We will start with a simple example in the style of the MDC and then improve it. For the sake of this example we will first assume that some sort of block((Things are usually encrypted in chunks (16 bytes long in most cases). The " | + | We will start with a simple example in the style of the MDC and then improve it. For the sake of this example we will first assume that some sort of block((Things are usually encrypted in chunks (16 bytes long in most cases). The " |
{{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. | + | We create this by [[wp> |
- | 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 they can somehow arrange to have an appropriate hash encrypted in 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 |
- | We can make it harder | + | It might be good to switch to a block encryption mode that is not so inherently easy to modify. The cipher feed back (CFB) block mode imposes a penalty on modification in the form of completely unpredictable random garbage in the block after the modified block((See |
{{mdc2.svg}} | {{mdc2.svg}} | ||
- | Now the attacker | + | Now the hash only has to detect the random garbage triggered by the attempt to change the CFB protected data. Since predicting the random garbage would require knowledge of the encryption key, the attacker has no real way to fix either the garbage or the hash. Attempts to change the last block of the message will cause unpredictable damage to the hash itself. So the modification detection code and the cipher feedback block mode work together. |
- | It might be good to switch to a block encryption mode that is not so inherently easy to modify. The cipher feed back (CFB) mode imposes | + | Changing the last block of the hash would not cause any random garbage because there is no place for that random garbage |
{{mdc3.svg}} | {{mdc3.svg}} | ||
- | Now the hash only has to detect | + | We have added some random data to the start of the message. The random |
- | Changing | + | There are some mostly theoretical attacks that involve getting the victim to encrypt messages created by the attacker so that the attacker then can modify them by chopping off the start and/ |
{{mdc4.svg}} | {{mdc4.svg}} | ||
- | We have added some random data before the length. That random data is included in the hash. That means that the attacker can never know the entire message | + | Now both the hash and the random data are protected |
- | This brings us to the end of our journey. The previous diagram represents the MDC (some irrelevant detail omitted). | + | If you want to attack |
* Everything is encrypted. You will have to work through the encryption. You don't know the key. | * Everything is encrypted. You will have to work through the encryption. You don't know the key. | ||
* The hash will detect your change directly. | * The hash will detect your change directly. | ||
- | * CFB will cause unpredictable damage to the next block which will also be detected by the hash. | + | * OCFB will cause unpredictable damage to the next block which will also be detected by the hash. |
- | * A changed length will be detected by the hash and will cause CFB damage. You don't know how to change it because of the encryption. | + | * Even if you can somehow figure out how to make a rational change to the message/ |
- | * Even if you can somehow figure out how to make a rational change to the message/ | + | * 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 the OpenPGP context. This was preexisting in the OpenPGP standard: | ||
+ | |||
+ | * The OCFB block mode is the standard mode used in OpenPGP. | ||
+ | * The random data is used by the OCFB block mode to prevent similar/ | ||
+ | |||
+ | All that was required to make the MDC was the addition of a single hash. The MDC is actually an example of minimalist and appropriate design. | ||
+ | |||
+ | I am not a professional cryptographer, | ||
- | This might seem clunky and redundant. | + | The combination of OCFB and MDC is effectively authenticated encryption. It detects changes |
- | * The length is the regular OpenPGP packet length. | + | Most authenticated encryption schemes use some sort of counter |
- | * The CFB block mode is the standard mode used in OpenPGP. | + | |
- | * The random | + | |
- | All that was required | + | The MDC uses the SHA1 method for the hash. Not everyone knows that the discovered weakness in SHA1 is irrelevant |
- | I am not a professional cryptographer, | + | The MDC is secure |
- | The combination of CFB and MDC is effectively authenticated encryption. It detects changes in messages based on the shared secret of the encryption key. There is a definition of authenticated encryption that makes refusal to release suspect data mandatory, but that is not relevant for the sort of offline applications that OpenPGP is used for. There is only one encrypted message/ | + | =====A Less Intuitive, More Technical Explanation===== |
- | Most authenticated encryption schemes use some sort of counter | + | OCFB-MDC is a case of hash then encrypt. The cipher |
+ | the addition of a prefix block consisting of random data. The traditional CFB initialization vector (IV) is replaced by the encryption | ||
+ | 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. | ||
- | The MDC uses the SHA1 method for the hash. Not everyone knows that the discovered weakness in SHA1 is irrelevant to the MDC. I suppose you could redefine it as the "MDC hash" | + | The modification detection code (MDC) is a SHA1 hash of the random data prefix block and the plaintext message. The inclusion of the random data makes the |
+ | MDC unpredictable | ||
- | The MDC is secure and is well suited | + | OCFB-MDC is immune |
+ | produce a second valid message. | ||
=====References===== | =====References===== | ||
Line 65: | Line 76: | ||
* [[https:// | * [[https:// | ||
* [[https:// | * [[https:// | ||
- | * [[https:// | + | * [[https:// |
+ | * [[https:// | ||
[[pgpfan: | [[pgpfan: | ||
[[em: | [[em: | ||
pgpfan/mdc.txt · Last modified: 2023/12/11 13:30 by b.walzer