The Call of the Open Sidewalk

From a place slightly to the side of the more popular path

User Tools

Site Tools

pgpfan:mdc

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
pgpfan:mdc [2022/05/28 19:57] – Typo b.walzerpgpfan:mdc [2023/12/11 13:30] (current) – Structure, we have to directly address the 16 bits of security thing 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:intptxt]] article for a related discussion.)). 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. 
 + 
 +Note that there is a another legend floating around that states that the MDC only has the equivalent of "16 bits of security". This is simply wrong and was probably the result of failing to read to the bottom of an email thread(([[https://mailarchive.ietf.org/arch/msg/openpgp/UYEBC7hnZNbMoNWrfz9zJQb_FUk/|The misread ITEF OpenPGP discussion thread about the security properties of the MDC]])).
  
 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. 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.
Line 13: Line 15:
 {{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 the message and compare that hash to the hash appended to the message.+We create this by [[wp>Cryptographic_hash_function|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 27: Line 29:
 {{mdc3.svg}} {{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.+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:ocfb|OpenPGP's Improved Cipher Feedback Mode]] article for some more detail.)) (OCFB) prevents that sort of attack by preventing attacker knowledge of the random prefix data and requiring the key to create a new random prefix. This is the OCFB-MDC (OpenPGP Cipher FeedBack - Modification Detection Code) mode used by OpenPGP (irrelevant detail omitted): 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:ocfb|OpenPGP's Improved Cipher Feedback Mode]] article for some more detail.)) (OCFB) prevents that sort of attack by preventing attacker knowledge of the random prefix data and requiring the key to create a new random prefix. This is the OCFB-MDC (OpenPGP Cipher FeedBack - Modification Detection Code) mode used by OpenPGP (irrelevant detail omitted):
  
 {{mdc4.svg}} {{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: If you want to attack OCFB-MDC and modify a message without triggering the MDC you will have to deal with the following challenges:
Line 41: Line 45:
   * 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 48: Line 52:
 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. 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, but the MDC seems pretty secure. No one can say for sure that the MDC is completely secure. Anyone can prove it is //not// by demonstrating that they can modify messages/files without tripping the MDC. In the 20 years that the MDC has existed (2022) no one has managed to do this.+I am not a professional cryptographer, but the MDC seems pretty secure. No one can say for sure that the MDC is completely secure. Anyone can prove it is //not// by demonstrating that they can modify messages/files without tripping the MDC. In the 20 years that the MDC has existed (2022) no one has managed to do this. I doubt that was because of a lack of effort. OpenPGP gets a fair bit of academic scrutiny.
  
 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/file available when working with an offline system. Eventually someone is going to have to look at a suspect message to try to determine if they are under some sort of attack. Someone might want to try to recover the data in a corrupted file. If you want to define OCFB-MDC-NR (NR for No Release) for some situation where that would make sense then feel free to do so; there is nothing intrinsic to OCFB-MDC that would prevent you from doing that. 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/file available when working with an offline system. Eventually someone is going to have to look at a suspect message to try to determine if they are under some sort of attack. Someone might want to try to recover the data in a corrupted file. If you want to define OCFB-MDC-NR (NR for No Release) for some situation where that would make sense then feel free to do so; there is nothing intrinsic to OCFB-MDC that would prevent you from doing that.
Line 56: Line 60:
 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 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. Proposals to add one or more encrypted authenticated modes and depreciate the MDC don't make sense to me. We would be better off if we simply did nothing.+The MDC is secure and is well suited to the sort of offline encryption that the OpenPGP standard embodies. [[pgpfan:no_new_ae|Proposals to add one or more encrypted authenticated modes and depreciate the MDC don't make sense to me]]. We would be better off if we simply did nothing.
  
 =====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.
  
 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 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.+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://cseweb.ucsd.edu/~mihir/papers/enc-red.pdf|Does encryption with redundancy provide authenticity?]])).
  
 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 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
Line 74: Line 78:
   * [[https://www.rfc-editor.org/rfc/rfc4880#section-5.13|RFC-4880 sec 5.13 (Symmetrically Encrypted Integrity Protected Data packet)]]   * [[https://www.rfc-editor.org/rfc/rfc4880#section-5.13|RFC-4880 sec 5.13 (Symmetrically Encrypted Integrity Protected Data packet)]]
   * [[https://www.rfc-editor.org/rfc/rfc4880#section-5.14|RFC-4880 sec 5.14 (Modification Detection Code packet)]]   * [[https://www.rfc-editor.org/rfc/rfc4880#section-5.14|RFC-4880 sec 5.14 (Modification Detection Code packet)]]
-  * [[https://mailarchive.ietf.org/arch/msg/openpgp/UYEBC7hnZNbMoNWrfz9zJQb_FUk/|IETF OpenPGP email list thread about the security properties of the MDC]] 
  
 [[pgpfan:index|PGP FAN index]]\\ [[pgpfan:index|PGP FAN index]]\\
 [[em:index|Encrypted Messaging index]] [[em:index|Encrypted Messaging index]]
  
pgpfan/mdc.1653767857.txt.gz · Last modified: 2022/05/28 19:57 by b.walzer