The Call of the Open Sidewalk

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

User Tools

Site Tools

pgpfan:no_new_ae

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:no_new_ae [2022/07/14 00:05] – [EFAIL] Forgot a category. b.walzerpgpfan:no_new_ae [2024/01/29 13:21] (current) – [OCFB-MDC uses the insecure SHA1 hash. Therefore OCFB-MDC is insecure] More specific. b.walzer
Line 3: Line 3:
 So... I have spent significant time writing PGP advocacy articles. The process involves digging into an old system in an attempt to figure out how it works. I apparently do things like that now. As my knowledge grew the articles evolved from spin to solid argument. It turned out that there was a lot of wisdom embedded in OpenPGP. I have recently discovered that the encryption framework used in OpenPGP (OCFB-MDC) is good and appropriate for the application. I am also aware that there has been at least one proposal in the past and a present proposal (2022) to replace it with something else. I don't think there are any good reasons to do that ... and what if I am right? It seems very possible to me that we have collectively forgotten (or never understood in the first place) why OCFB-MDC works. That suggests that the status quo should have a champion. That creates an obligation on my part. Hence this editorial. So... I have spent significant time writing PGP advocacy articles. The process involves digging into an old system in an attempt to figure out how it works. I apparently do things like that now. As my knowledge grew the articles evolved from spin to solid argument. It turned out that there was a lot of wisdom embedded in OpenPGP. I have recently discovered that the encryption framework used in OpenPGP (OCFB-MDC) is good and appropriate for the application. I am also aware that there has been at least one proposal in the past and a present proposal (2022) to replace it with something else. I don't think there are any good reasons to do that ... and what if I am right? It seems very possible to me that we have collectively forgotten (or never understood in the first place) why OCFB-MDC works. That suggests that the status quo should have a champion. That creates an obligation on my part. Hence this editorial.
  
-OCFB stands for OpenPGP Cipher Feed Back. It is OpenPGP's improved version of the traditional cipher feedback block encryption mode(([[wp>Block_cipher_mode_of_operation#Full-block_CFB|Cipher Feedback Block Cipher Mode]])). It increases the difficulty of modification of messages/files by malicious entities. It is like a vault in a bank that increases the difficulty of modifying the location of the money. MDC stands for Modification Detection Code. It is the means to detect modification of the encrypted data. It is like the alarm on the bank vault. The two things work together and are should only used together. The combination should be considered a single OCFB-MDC mode and that is what I will be calling it here((The OpenPGP standard calls the OCFB-MDC mode the Symmetrically Encrypted Integrity Protected Data (SEIPD) packet (tag 18) but none of that would add anything to the clarity of my discussion.)). The OCFB-MDC mode is used when anything is encrypted in OpenPGP format. It has existed for over two decades (2022). So it is a very well established part of the standard. So we should expect that proposals to supersede it would come with strong justification for the change. This article takes the form of a search for such justification. On the journey I hope to show that there is nothing wrong with OCFB-MDC and that it is suited for OpenPGP in ways that typical proposals are not. Unfortunately, I have not been able to find any inclusive change rationale so this will mostly be based on what I think the arguments are as gleaned from discussions and blog posts.+OCFB stands for OpenPGP Cipher Feed Back. It is OpenPGP's improved version of the traditional cipher feedback block encryption mode(([[wp>Block_cipher_mode_of_operation#Full-block_CFB|Cipher Feedback Block Cipher Mode]])). It increases the difficulty of modification of messages/files by malicious entities. It is like a vault in a bank that increases the difficulty of modifying the location of the money. MDC stands for Modification Detection Code. It is the means to detect modification of the encrypted data. It is like the alarm on the bank vault. The two things work together and are only used together. The combination should be considered a single OCFB-MDC mode and that is what I will be calling it here((The OpenPGP standard calls the OCFB-MDC mode the Symmetrically Encrypted Integrity Protected Data (SEIPD) packet (tag 18) but none of that would add anything to the clarity of my discussion.)). The OCFB-MDC mode is used when anything is encrypted in OpenPGP format. It has existed for over two decades (2022). So it is a very well established part of the standard. So we should expect that proposals to supersede it would come with strong justification for the change. I have not been able to find such justification. I hope to show that there is nothing wrong with OCFB-MDC and that it is suited for OpenPGP in ways that typical proposals are not. Unfortunately, I have not been able to find any inclusive change rationale so this will mostly be based on what I think the arguments are as gleaned from discussions and blog posts.
  
 We should be clear at the start about the cost of of replacing OCFB-MDC with something else. That would cause hard to understand interoperability problems whenever the OpenPGP preference system fails to work((A "PGP PUBLIC KEY" gets the preferences of the application it was generated on. It is common for users to use multiple OpenPGP applications.)) or is not applicable((Whenever symmetric encryption is used.)). Some implementations will simply never implement the replacement. We are still occasionally seeing interoperability problems caused by the use of OCFB (the thing before OCFB-MDC) two decades after it was superseded by OCFB-MDC. By the very nature of the sort of problem OpenPGP is intended to solve, there can be no central authority to drive change. Change takes a long time and it isn't possible to get rid of the old thing until everyone is done with their archive of encrypted email and/or files. So this is really about an addition to everything that is already there, not a replacement. We should be clear at the start about the cost of of replacing OCFB-MDC with something else. That would cause hard to understand interoperability problems whenever the OpenPGP preference system fails to work((A "PGP PUBLIC KEY" gets the preferences of the application it was generated on. It is common for users to use multiple OpenPGP applications.)) or is not applicable((Whenever symmetric encryption is used.)). Some implementations will simply never implement the replacement. We are still occasionally seeing interoperability problems caused by the use of OCFB (the thing before OCFB-MDC) two decades after it was superseded by OCFB-MDC. By the very nature of the sort of problem OpenPGP is intended to solve, there can be no central authority to drive change. Change takes a long time and it isn't possible to get rid of the old thing until everyone is done with their archive of encrypted email and/or files. So this is really about an addition to everything that is already there, not a replacement.
Line 16: Line 16:
 This discussion assumes a normal OpenPGP usage scope of encrypting messages (e.g. email) and files. This is an important qualification. Any tool can be shown to be deficient simply by expanding the use scope of that tool. My hammer does a terrible job of driving screws, but that does not mean it is broken... This discussion assumes a normal OpenPGP usage scope of encrypting messages (e.g. email) and files. This is an important qualification. Any tool can be shown to be deficient simply by expanding the use scope of that tool. My hammer does a terrible job of driving screws, but that does not mean it is broken...
  
-Please forgive the length. Since I have gone to all the trouble to have positions on all these issues I can't not include them in an editorial where they are directly related.+=====Discussion=====
  
-=====OCFB-MDC is cryptographically insecure=====+OCFB-MDC seems to work well in practice against modification even if the detection (MDC) is ignored. I believe that is because:
  
-It is often implied that OCFB-MDC is insecure in some way but there doesn't seem to be any actual evidence for this. Here is a collection of the most definite implications that I have stumbled across...+  * OCFB provides inherent modification deterrence. Modification comes with a cost for the attacker. 
 +  * [[pgpfan:no_new_ae#efail_but_better_jallad_et_al_2002|OCFB serves as a witness of an attack]] after the price has been paid. A victim ends up with definite proof of the attack. 
 + 
 +The properties of the offline non-connection medium that OpenPGP specifies are helpful: 
 + 
 +  * There is no useful backchannel to use for oracle attacks. 
 +  * There is only one attempt available. 
 +  * The victim ends up with a copy of the attack message/file. 
 + 
 +As a result, attacks that involve modification of the encrypted data likely have a higher cost than the potential benefit. 
 + 
 +[[pgpfan:efail|EFAIL]] was a successful attack against this traditional inherent modification deterrence for the case where the modification detection is not used. The victim still ends up with incontrovertible proof of an attack, so the success was partial. 
 + 
 +Where the modification detection of OCFB-MDC //is// used, EFAIL is completely prevented. So there would be no possible further benefit provided here by adding another cipher feedback mode to the OpenPGP standard. EFAIL does not justify the replacement of OCFB-MDC. 
 + 
 +It [[pgpfan:no_new_ae#openpgp_should_not_release_suspect_data_and_hash_then_encrypt_has_to_go|has been shown]] that EFAIL can be solved in a valid way that is arguably superior to the approach of having the cryptography code refuse to release data. This is important as it is often assumed that refusing to release data is the only reasonable method of preventing attacks involving modification of encrypted data. However, if it is desired to solve the problem of maliciously modified encrypted data by refusing to release data, there is nothing inherent to OCFB-MDC that prevents that use at the potential cost of usability. 
 + 
 +OCFB-MDC is cryptographically secure in that a protected message can not be modified without detection. It provides the capability of the sort of thing often referred to as authenticated encryption. So the OpenPGP standard does not lack authenticated encryption as is sometimes claimed. 
 + 
 +I have come to believe that OpenPGP gains its legendary effectiveness mostly from the [[pgpfan:minimalist|minimal approach]] taken. So I am disturbed by how much extra complexity these proposals add to the standard. As a definite example, the proposal currently (September 2022) working through the IETF process adds the following: 
 + 
 +  * Three new cipher block modes. Since the standard currently has two such modes (OCFB-CFB and the proceeding OCFB) that brings the total to five. 
 +  * Since there are so many block modes,  it becomes necessary to create an entirely new preferences system to deal with this fact. 
 +  * Since these modes come from online, connection oriented media like TLS they tend to be limited in how much data they can process at once. As a result a [[pgpfan:no_new_ae#decrypting_large_files_should_not_result_in_the_release_of_suspect_data|"chunking" system]] has to be added to the standard. With the current two levels of blocking that brings the number of blocking levels to three. 
 + 
 +To be clear, this is not about any encryption mode. OpenPGP implementations normally use the [[wp>Advanced_Encryption_Standard|AES]] encryption mode and there is no proposal to change this. This is about the relatively obscure [[wp>Block_cipher_mode_of_operation|block cipher mode]]. The only definite outcome of replacing the current block cipher mode (OCFB-MDC) will be to cause interoperability problems. The current proposal for such replacement makes the potential for such problems much worse by making two of the three added modes optional.  
 + 
 +=====Conclusion===== 
 + 
 +The problems caused by these harmful proposals are not off in the future. [[pgpfan:noae_shame|They are causing trouble today]] even though none have made it into the OpenPGP standard (2022). I have personally been involved in an obscure and hard to fix interoperability problem caused by one of these proposed encryption modes that had somehow leaked out of an implementation. There was no evidence that the user had explicitly authorized the use of the mode. The GnuPG implementation actually had a possible remote code execution exploit(([[https://nvd.nist.gov/vuln/detail/CVE-2020-25125|CVE-2020-25125]])) caused by the implementation of the new preferences system required to deal with the proliferation of block cipher modes. The issue was quickly rectified but I could not ask for a better example of the risk associated with implementing new functionality. 
 + 
 +The Snowden leak (([[https://blog.cryptographyengineering.com/2014/12/29/on-new-snowden-documents/|On the new Snowden documents]])) had documents that suggested PGP encrypted material was on a short list of things that the NSA(([[wp>National_Security_Agency|National Security Agency]])) could not get access to. That likely was for passive eavesdropping but this still suggests that it might not be a good time to tinker with the fundamental cryptography of OpenPGP without good reason. 
 + 
 +Long existing standards should not be modified in incompatible ways unless things are fairly dire. We should remember that the "extend then extinguish" principle often used to degrade or destroy standards still applies, even if the intentions behind the extend part are good. Changes made without strong justification are particularly likely to cause trouble in an instance like OpenPGP where there is no strong single entity to enforce those changes. Long existing standards are not important because of their technical superiority. They are important simply because they //are// long existing standards. Even if there were some sort of weakness in OCFB-MDC the first approach should involve some sort of interoperable workaround and not complete replacement. But here we see attempts to replace a subsystem that is working well. None of the issues discussed here have caused an actual user of OpenPGP embarrassment or even inconvenience over the last 20 years (2022). How likely is it that we would be so lucky in the case of a OCFB-MDC replacement?  
 + 
 +This editorial was created to support these points: 
 + 
 +  * The current OpenPGP block cipher mode (OCDF-MDC)  is secure and appropriate and should not be replaced. 
 +  * The OpenPGP standard should not suggest or attempt to mandate that data that is suspected of malicious modification should be withheld from any entity. It is better to complete the operation and then provide the status. 
 + 
 +This quote seems relevant here: 
 + 
 +>In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, 'I don't see the use of this; let us clear it away.' To which the more intelligent type of reformer will do well to answer: 'If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.'\\ 
 +//Chesterton, G. K. (1929)// 
 + 
 +[[pgpfan:index|PGP FAN index]]\\ 
 +[[em:index|Encrypted Messaging index]]\\ 
 +[[:start|Home]] 
 + 
 +---- 
 + 
 +=====Counterarguments===== 
 + 
 +The following is a detailed series of counterarguments to objections to OCFB-MDC. The reader can skip these unless they have a particular interest in one or more of them. 
 + 
 +It is often implied that OCFB-MDC is cryptographically insecure in some way but there doesn't seem to be any actual evidence for this. Here is a collection of the most definite implications that I have stumbled across...
  
 ====Hash then encrypt is generically insecure==== ====Hash then encrypt is generically insecure====
Line 39: Line 94:
  
 We should not fail to recognize that hash then encrypt has a significant advantage over other methods in that it protects the integrity check with the encryption. An attacker has to work through the encryption to attack the check. We should not fail to recognize that hash then encrypt has a significant advantage over other methods in that it protects the integrity check with the encryption. An attacker has to work through the encryption to attack the check.
 +
 +===OpenPGP's OCFB-MDC is inferior because it falls into the class of INT-PTXT instead of the class of INT-CTXT===
 +
 +This is essentially the idea that hash then encrypt is inferior expressed in the language of theoretical cryptography. Since we know the design of OCFB-MDC we can address this directly.
 +
 +Because of that design you have to decrypt the message/file first before checking for any changes. So there is a risk that the message/file might leak or be caused to leak during that check. After the check you can blow up with an error if you want and prevent any further chance of a leak.
 +
 +The check here is the hash called SHA-1. As with most hashes, the time taken is not affected by the content that is being checked. It would be pretty much impossible to make the time taken depend on the content by accident. Since this is a hash, it acts to destroy the meaning of the content to prevent the hash from being reversed. So some sort of side channel leak is very unlikely.
 +
 +So when someone brings up the fact that OCFB-MDC is INT-PTXT they are really saying they think that a hash operation might leak information. They would have to come up with some idea of how that might happen.
  
 ====OpenPGP does not have authenticated encryption. Everything needs authenticated encryption.==== ====OpenPGP does not have authenticated encryption. Everything needs authenticated encryption.====
Line 48: Line 113:
 ====OCFB-MDC uses the insecure SHA1 hash. Therefore OCFB-MDC is insecure==== ====OCFB-MDC uses the insecure SHA1 hash. Therefore OCFB-MDC is insecure====
  
-According to a partially remembered email list post, the MDC only requires a hash that is non-reversible. That seems quite reasonable to me. So the currently known SHA1 collision weakness does not affect the security of OCFB-MDC in any way. I understand that the mere presence of something called SHA1 can cause problems in some situations, but such restrictions are not rational. If this is actually a problem then I suggest that the SHA1 used for OCFB-MDC be renamed to something like "The MDC Hash" and be respecified to only provide irreversability.+From the appropriate discussion section of OpenPGP standard: 
 + 
 +>It does not rely on a hash function being collision-free, it relies on a hash function being one-way. 
 + 
 +So the currently known SHA1 collision weakness does not affect the security of OCFB-MDC in any way. OCFB-MDC prevents an attacker from getting access to the computed hash or even to generate a valid hash with the aid of an encryption oracle. So I would go so far as to say that a good one-way function is not really required. All that is needed is a function that can reliably detect changes to the protected message. Some classes of [[wp>Cyclic_redundancy_checkcheck|CRC]] might be sufficient for example. 
 + 
 +I understand that the mere presence of something called SHA1 can cause problems in some situations, but such restrictions are not rational. If this is actually a problem then I suggest that the SHA1 used for OCFB-MDC be renamed to something like "The MDC Hash" and be respecified to only provide irreversability.
  
 Because OCFB-MDC protects the output of the hash by randomizing and then encrypting it, it seems reasonable to think that it is more resistant to weaknesses in the hash than the commonly used schemes that expose the output of the hash to the attacker. So replacing OCFB-MDC with such a scheme might increase the probability of trouble down the road. If we were to take a stand against harmful changes prompted by broken policies covering the use of certain cryptographic functions, we couldn't really find a better place to take that stand than with SHA1 usage in OCFB-MDC. It isn't that we got lucky somehow here, the collision resistance of the hash used in OCFB-MDC is simply irrelevant. Because OCFB-MDC protects the output of the hash by randomizing and then encrypting it, it seems reasonable to think that it is more resistant to weaknesses in the hash than the commonly used schemes that expose the output of the hash to the attacker. So replacing OCFB-MDC with such a scheme might increase the probability of trouble down the road. If we were to take a stand against harmful changes prompted by broken policies covering the use of certain cryptographic functions, we couldn't really find a better place to take that stand than with SHA1 usage in OCFB-MDC. It isn't that we got lucky somehow here, the collision resistance of the hash used in OCFB-MDC is simply irrelevant.
Line 55: Line 126:
  
 This came from a blog post called [[pgpfan:tpp|The PGP Problem]]. It turned out to be a misunderstanding caused by an incorrect specification. The author of the blog post misunderstood the discussion. There is no such weakness. This came from a blog post called [[pgpfan:tpp|The PGP Problem]]. It turned out to be a misunderstanding caused by an incorrect specification. The author of the blog post misunderstood the discussion. There is no such weakness.
 +
 +====OCFB-MDC doesn't have a security proof====
 +
 +Instead of a criticism of the //design// of OCFB-MDC this is about a design //method//. This objection has the great advantage of not raising a specific issue. Vague contentions are hard to refute.
 +
 +The proof here is something like a mathematical proof created to support something kind of like an engineering process. Practically, it is a proof that generally accepted engineering principles were applied to the design. The important point here is that such a thing does not prove security directly, only indirectly through those design principles.
 +
 +Like any design process based on mathematical/logical principles, security proofs live and die on their assumptions. Cryptographic constructions with security proofs are still successfully attacked. Only at that point does it becomes clear what assumption was incorrect. That assumption might of even been implicit and unknown to the designer.
 +
 +So a security proof is not proof of security...
 +
 +A popular bridge design might of come from a process based on slide rules, algebra, lookup tables, cigarettes and coffee. If those bridges exist all over the country, would it make any sense to propose that they all be torn down and rebuilt using a newer design?
 +
 +If it turned out that the bridges were reliable, easy to inspect and inexpensive it would make more sense to use the bridge as an example to extend and improve the state of the art. That is the situation with OCFB-MDC. A simple, easy to understand design that has very much stood the test of time. It makes no sense to complain about the design process of something that has already proven itself secure. That is after all the hoped for result of applying generally accepted engineering principles in the first place.
  
 ====The MDC can be stripped==== ====The MDC can be stripped====
Line 69: Line 154:
 If the receiver requires the MDC of the integrity checked version of the message then it can't accept the non-integrity checked version no matter where it comes from. It makes no real difference in practice if it has been downgraded. If the receiver requires the MDC of the integrity checked version of the message then it can't accept the non-integrity checked version no matter where it comes from. It makes no real difference in practice if it has been downgraded.
  
-The rest of this article will assume that OCFB-MDC is cryptographically secure. If you, the reader, disagree then please demonstrate a modification not caught by the MDC check and save us all a lot of time and trouble. Some theoretical preference for one method over another would of been good 20 years ago but at this point we would have to break it to discredit it. This is a very good conclusion. It means that the OCFB-MDC message format does not have to change or be replaced. The very best outcome of an attempt to change a long established standard is the realization that the standard is fine as it is.+----
  
-So most of the rest of this will be about the idea that OpenPGP should not release data that is suspected of being maliciously modified. One could take that approach with OCFB-MDC by refusing to release data on an invalid MDC check, but I will try to show that that is something that should not be done as a matter of policy.+The rest of these counterarguments will assume that OCFB-MDC is cryptographically secure. If you, the reader, disagree then please demonstrate a modification not caught by the MDC check and save us all a lot of time and trouble. Some theoretical preference for one method over another would of been good 20 years ago but at this point we would have to break it to discredit it. This is a very good conclusion. It means that the OCFB-MDC message format does not have to change or be replaced. The very best outcome of an attempt to change a long established standard is the realization that the standard is fine as it is.
  
-=====Some Relevant Issues=====+So most of the rest of this will be about the idea that OpenPGP should not release data that is suspected of being maliciously modified. One could take that approach with OCFB-MDC by refusing to release data on an invalid MDC check, but I will try to show that that is something that should not be done as a matter of policy.
  
 ====EFAIL==== ====EFAIL====
Line 170: Line 255:
 ===EFAIL but Better (Jallad et al., 2002)=== ===EFAIL but Better (Jallad et al., 2002)===
  
-The first is the same sort of thing as EFAIL, although it predates EFAIL by 16 years(([[https://www.cs.umd.edu/~jkatz/papers/pgp-attack.pdf|Implementation of Chosen-Ciphertext Attacks against PGP and GnuPG]])). Instead of tricking an HTML interpreter into sending the decrypted message to the attacker as in EFAIL, this attack instead tricks the user into sending the decrypted message back to the attacker. That message was disguised by flipping random bits to prevent the user from recognizing the message. The idea was that the user might return the disguised message to the sender with a query. This might seem like a trivial attack, but the researchers had to work around the inherent modification deterrence of OCFB which added significant difficulty. The existence of this attack does not support the replacement of OCFB-MDC for the same reason as in the EFAIL case: there is nothing that a replacement scheme could do that could not be done with OCFB-MDC.+The first is the same sort of thing as EFAIL, although it predates EFAIL by 16 years(([[https://www.cs.umd.edu/~jkatz/papers/pgp-attack.pdf|Implementation of Chosen-Ciphertext Attacks against PGP and GnuPG]])). Instead of tricking an HTML interpreter into sending the decrypted message to the attacker as in EFAIL, this attack instead tricks the user into sending the decrypted message back to the attacker. That message was disguised by flipping random bits to prevent the user from recognizing the message. The idea was that the user might return the decrypted but disguised message to the sender with a query. This might seem like a trivial attack, but the researchers had to work around the inherent modification deterrence of OCFB which added significant difficulty. The existence of this attack does not support the replacement of OCFB-MDC for the same reason as in the EFAIL case: there is nothing that a replacement scheme could do that could not be done with OCFB-MDC.
  
 The original researchers were not able (or didn't bother) to make the attack practical but there is no reason to think that this would be impossible or even all that hard. In the 20 years (2022) this attack has existed there seem to have been no attempts at actual use. We would very likely know that such attack was attempted because in an offline non-connection medium like email the recipient always gets the attack message. We would know that it was an actual attack and not just random corruption of the message because of the work required to defeat OCFB. This is a point. The deterrence against modification provided by OCFB does not end when an attacker works around it. That work then provides a sort of witness function that proves an attack. What attacker wants to send their victim incontrovertible evidence that they are under attack on the first attempt? Particularly in cases where that first attack was likely to fail? The original researchers were not able (or didn't bother) to make the attack practical but there is no reason to think that this would be impossible or even all that hard. In the 20 years (2022) this attack has existed there seem to have been no attempts at actual use. We would very likely know that such attack was attempted because in an offline non-connection medium like email the recipient always gets the attack message. We would know that it was an actual attack and not just random corruption of the message because of the work required to defeat OCFB. This is a point. The deterrence against modification provided by OCFB does not end when an attacker works around it. That work then provides a sort of witness function that proves an attack. What attacker wants to send their victim incontrovertible evidence that they are under attack on the first attempt? Particularly in cases where that first attack was likely to fail?
Line 181: Line 266:
  
 Even if we accept that such an oracle is possible with some sort of usage wildly out of the scope of normal OpenPGP use then there is still no need to replace OCFB-MDC. To destroy the oracle all that is needed is to ignore the quick check. The actual message format would not change and interoperability would remain complete. Even if we accept that such an oracle is possible with some sort of usage wildly out of the scope of normal OpenPGP use then there is still no need to replace OCFB-MDC. To destroy the oracle all that is needed is to ignore the quick check. The actual message format would not change and interoperability would remain complete.
 +
 +Please see the [[pgpfan:oracle|Oracle Attack Immunity]] article for a discussion of how this particular attack relates to normal PGP usage.
  
 ====Decrypting large files should not result in the release of suspect data==== ====Decrypting large files should not result in the release of suspect data====
Line 193: Line 280:
  
 Second, we have increased the complexity of the structure of all OpenPGP encrypted messages/files. Currently there are two levels of blocking used in OpenPGP: The fixed length block encryption structure and the variable length blocking provided by the packet structure. This would add another level of blocking for a total of three. That provides attackers another set of block boundaries to work against and greatly increases the number of ways program logic can get things wrong. This would provide attackers with many encryption cycles to work against instead of just one. In general, greater complexity leads to less security and reliability. Second, we have increased the complexity of the structure of all OpenPGP encrypted messages/files. Currently there are two levels of blocking used in OpenPGP: The fixed length block encryption structure and the variable length blocking provided by the packet structure. This would add another level of blocking for a total of three. That provides attackers another set of block boundaries to work against and greatly increases the number of ways program logic can get things wrong. This would provide attackers with many encryption cycles to work against instead of just one. In general, greater complexity leads to less security and reliability.
 +
 +Libraries will now have to present a different interface that takes this blocking into account. Applications will have to be rewritten.
  
 Integrity check blocking means that an attacker can trivially modify an encrypted file simply by causing a bit error in the block before the block that will become the last one. This seems kind of ironic considering what this is ultimately all about. Integrity check blocking means that an attacker can trivially modify an encrypted file simply by causing a bit error in the block before the block that will become the last one. This seems kind of ironic considering what this is ultimately all about.
Line 198: Line 287:
 It is not all that clear that blowing up with an error and not releasing suspect data is the optimal behaviour for suspected modification of large files. The vast majority of such errors are going to be caused by bad data that evolved naturally in the large file. A user might want to attempt recovery and so will have to be given access to the suspect data much like in the EFAIL case. I am not sure that many actual users were consulted here, this came out of nowhere. I strongly suspect that it entirely came out of the idea that OpenPGP should not release data that is suspected of malicious modification and is based on no practical need at all. It is not all that clear that blowing up with an error and not releasing suspect data is the optimal behaviour for suspected modification of large files. The vast majority of such errors are going to be caused by bad data that evolved naturally in the large file. A user might want to attempt recovery and so will have to be given access to the suspect data much like in the EFAIL case. I am not sure that many actual users were consulted here, this came out of nowhere. I strongly suspect that it entirely came out of the idea that OpenPGP should not release data that is suspected of malicious modification and is based on no practical need at all.
  
-Since the code/libraries available for these proposed modes practically //can't// release unverified data due to how they do things, they will come with a maximum message size specification. So, in practice, some sort of blocking scheme for long files is //mandatory//. So this can be seen as an example of an awkward workaround caused by the inappropriate application of online connected encryption modes to an offline non-connection application.+Since the code/libraries available for these proposed modes practically //can't// release unverified data due to how they do things, they will come with a maximum message size specification. So, in practice, some sort of blocking scheme for long files is //mandatory//. So this can be seen as an example of an awkward workaround caused by the inappropriate application of online connection oriented encryption modes to offline non-connection oriented media.
  
 The fix requires zero effort. Just leave things as they are. The blocking issue serves as a serious argument against the replacement of OCFB-MDC. The fix requires zero effort. Just leave things as they are. The blocking issue serves as a serious argument against the replacement of OCFB-MDC.
  
-=====Summary/Discussion=====+[[pgpfan:index|PGP FAN index]]\\ 
 +[[em:index|Encrypted Messaging index]]\\ 
 +[[:|Home]]
  
-OCFB-MDC is cryptographically secure in that a protected message can not be modified without detection. It provides the capability of the sort of thing normally referred to as authenticated encryption. 
  
-OCFB-MDC seems to work well in practice against modification even if the detection is ignored. I believe that is because: 
- 
-  * OCFB provides inherent modification deterrence. Modification comes with a cost for the attacker. 
-  * OCFB serves as a witness of an attack after the price has been paid. A victim ends up with definite proof of the attack. 
- 
-The properties of the offline non-connection medium are helpful: 
- 
-  * There is no useful backchannel to use for oracle attacks. 
-  * The victim ends up with a copy of the attack message/file. 
- 
-As a result, attacks that involve modification of the encrypted data likely have a higher cost than the potential benefit. 
- 
-EFAIL was a successful attack against this traditional inherent modification deterrence for the case where the modification detection is ignored. The victim still ends up with incontrovertible proof of an attack, so the success here is partial. 
- 
-As demonstrated, EFAIL can be solved in a valid way that is arguably superior to the approach of having the cryptography code refuse to release data. 
- 
-The MDC seems to be able to reliably detect modification and can be used where required to reduce the probability of successful attacks involving such modification. Yes, it could be used as part of some policy that involves not releasing suspect data but I believe that such a policy used in an offline non-connection medium would ultimately come at the cost of usability. At any rate, there is no good reason to replace OCFB-MDC with something else and multiple reasons why that would be a bad idea. 
- 
-=====Conclusion===== 
- 
-The problems caused by these harmful proposals are not off in the future. They are causing trouble today even though none have made it into the OpenPGP standard (2022). I have personally been involved in an obscure and hard to fix interoperability problem caused by one of these proposed encryption modes that had somehow leaked out of an implementation. There was no evidence that the user had explicitly authorized the use of the mode. The GnuPG implementation actually had a possible remote code execution exploit(([[https://nvd.nist.gov/vuln/detail/CVE-2020-25125|CVE-2020-25125]])) caused by the implementation of some of the OCFB-MDC replacement candidates that existed at the time. The issue was quickly rectified but I could not ask for a better example of the risk associated with implementing new functionality. 
- 
-The Snowden leak (([[https://blog.cryptographyengineering.com/2014/12/29/on-new-snowden-documents/|On the new Snowden documents]])) had documents that suggested PGP encrypted material was on a short list of things that the NSA(([[wp>National_Security_Agency|National Security Agency]])) could not get access to. That likely was for passive eavesdropping but this still suggests that it might not be a good idea to tinker with the fundamental cryptography of OpenPGP without good reason. 
- 
-Long existing standards should not be modified in incompatible ways unless things are fairly dire. We should remember that the "extend then extinguish" principle often used to degrade or destroy standards still applies, even if the intentions behind the extend part are good. Changes made without strong justification are particularly likely to cause trouble in an instance like OpenPGP where there is no strong single entity to enforce those changes. Long existing standards are not important because of their technical superiority. They are important simply because they //are// long existing standards. Even if there were some sort of weakness in OCFB-MDC the first approach should involve some sort of interoperable workaround and not complete replacement. But here we see attempts to replace a subsystem that is working well. None of the issues discussed here have caused an actual user of OpenPGP embarrassment or even inconvenience over the last 20 years (2022). How likely is it that we would be so lucky in the case of a OCFB-MDC replacement?  
- 
-This editorial was created to support these points: 
- 
-  * The current OpenPGP encryption mode is secure and appropriate and should not be replaced. 
-  * The OpenPGP standard should not suggest or attempt to mandate that data that is suspected of malicious modification should be withheld from any entity. It is better to complete the operation and then provide the status. 
- 
-This quote seems relevant: 
- 
->In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, 'I don't see the use of this; let us clear it away.' To which the more intelligent type of reformer will do well to answer: 'If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.'\\ 
-//Chesterton, G. K. (1929)// 
- 
-[[pgpfan:index|PGP FAN index]]\\ 
-[[em:index|Encrypted Messaging index]] 
  
pgpfan/no_new_ae.1657757151.txt.gz · Last modified: 2022/07/14 00:05 by b.walzer