pgpfan:mdc
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revisionLast revisionBoth sides next revision | ||
pgpfan:mdc [2020/09/17 16:17] – created b.walzer | pgpfan:mdc [2023/12/11 13:03] – Accuracy. b.walzer | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ======Modification Detection Code====== | + | ======The OpenPGP |
- | Normally, when PGP is used for messaging | + | I once worked |
- | You can also encrypt something without a signature. That might conceivably be done in a messaging context for an anonymous but private message. For something like a backup | + | 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 // |
- | It was quickly pointed out that it could be removed entirely without any indication. In the PGP ecosystem | + | When OpenPGP is used for something like email, |
- | The MDC turned out to be surprisingly robust against attempts | + | 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 |
- | [[pgpfan: | + | 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}} | ||
+ | |||
+ | 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 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. | ||
+ | |||
+ | 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 the [[pgpfan: | ||
+ | |||
+ | {{mdc2.svg}} | ||
+ | |||
+ | 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. | ||
+ | |||
+ | Changing the last block of the hash would not cause any random garbage because there is no place for that random garbage to go. This means that at least a portion of the hash is modifiable. Let's fix that: | ||
+ | |||
+ | {{mdc3.svg}} | ||
+ | |||
+ | We have added some random data to the start of the message. The random data prefix is included in the hash. That means that the attacker can never know the entire message and as a result will not know what the hash is to start with. As a result they will not be able to change the hash in a rational way by flipping bits. So the hash is protected by first randomizing it and then encrypting it. | ||
+ | |||
+ | 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/or the end of the message without detection. The version of cipher feedback used by OpenPGP((See the [[pgpfan: | ||
+ | |||
+ | {{mdc4.svg}} | ||
+ | |||
+ | Now both the hash and the random data are protected by first randomizing them and then encrypting them. | ||
+ | |||
+ | If you want to attack OCFB-MDC and modify a message without triggering the MDC you will have to deal with the following challenges: | ||
+ | |||
+ | * Everything is encrypted. You will have to work through the encryption. You don't know the key. | ||
+ | * The hash will detect your change directly. | ||
+ | * OCFB will cause unpredictable damage to the next block which will also be detected by the hash. | ||
+ | * 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, | ||
+ | |||
+ | The combination of OCFB 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/ | ||
+ | |||
+ | Most authenticated encryption schemes use some sort of counter block encryption mode and as a result depend heavily on the implementation refusing to release suspect data because counter mode is completely modifiable without penalty. In an offline encryption environment where such implementation behaviour can't be guaranteed, the inherent modification deterrence of the OCFB mode becomes important. So the MDC is specifically suited to the offline encryption environment in a way that other schemes are not. | ||
+ | |||
+ | 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" and specify that it only needs to be irreversible to prevent unnecessary angst. In general, the MDC is likely to be resistant to weaknesses in the hash due to the fact that the stored hash is encrypted and randomized by the random data which makes it very hard to mess with. | ||
+ | |||
+ | The MDC is secure and is well suited to the sort of offline encryption that the OpenPGP standard embodies. [[pgpfan: | ||
+ | |||
+ | =====A Less Intuitive, More Technical Explanation===== | ||
+ | |||
+ | 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. | ||
+ | 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 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 and prevents known plaintext based modification. It has been argued that making the hash unavailable to the attacker in this way is a requirement for a secure construct of this type(([[https:// | ||
+ | |||
+ | OCFB-MDC is immune to the classic attacks against hash then encrypt that involve getting the victim to encrypt an attack message that is later truncated to | ||
+ | produce a second valid message. | ||
+ | |||
+ | =====References===== | ||
+ | |||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | |||
+ | [[pgpfan: | ||
+ | [[em: | ||
pgpfan/mdc.txt · Last modified: 2023/12/11 13:30 by b.walzer