pgpfan:no_new_ae
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:no_new_ae [2022/07/18 22:38] – [Decrypting large files should not result in the release of suspect data] Minor consistency fix b.walzer | pgpfan:no_new_ae [2024/01/06 16:41] – [Hash then encrypt is generically insecure] closer 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' | + | OCFB stands for OpenPGP Cipher Feed Back. It is OpenPGP' |
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 |
- | It is often implied that OCFB-MDC is insecure in some way but there doesn' | + | * OCFB provides inherent modification deterrence. Modification comes with a cost for the attacker. |
+ | * [[pgpfan: | ||
+ | |||
+ | 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/ | ||
+ | |||
+ | As a result, attacks that involve modification of the encrypted data likely have a higher cost than the potential benefit. | ||
+ | |||
+ | [[pgpfan: | ||
+ | |||
+ | 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: | ||
+ | |||
+ | 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: | ||
+ | |||
+ | * 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, | ||
+ | * 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: | ||
+ | |||
+ | To be clear, this is not about any encryption mode. OpenPGP implementations normally use the [[wp> | ||
+ | |||
+ | =====Conclusion===== | ||
+ | |||
+ | The problems caused by these harmful proposals are not off in the future. [[pgpfan: | ||
+ | |||
+ | The Snowden leak (([[https:// | ||
+ | |||
+ | Long existing standards should not be modified in incompatible ways unless things are fairly dire. We should remember that the " | ||
+ | |||
+ | This editorial was created to support these points: | ||
+ | |||
+ | * The current OpenPGP block cipher mode (OCDF-MDC) | ||
+ | * 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.' | ||
+ | // | ||
+ | |||
+ | [[pgpfan: | ||
+ | [[em: | ||
+ | [[: | ||
+ | |||
+ | ---- | ||
+ | |||
+ | =====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 | ||
====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' | ||
+ | |||
+ | 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/ | ||
+ | |||
+ | 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 55: | Line 120: | ||
This came from a blog post called [[pgpfan: | This came from a blog post called [[pgpfan: | ||
+ | |||
+ | ====OCFB-MDC doesn' | ||
+ | |||
+ | 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, | ||
+ | |||
+ | Like any design process based on mathematical/ | ||
+ | |||
+ | 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 148: | ||
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 | + | The rest of these counterarguments |
- | =====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 249: | ||
===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:// | + | The first is the same sort of thing as EFAIL, although it predates EFAIL by 16 years(([[https:// |
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 260: | ||
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: | ||
====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 204: | Line 285: | ||
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/ | + | [[pgpfan: |
- | + | [[em: | |
- | 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. | + | [[:|Home]] |
- | 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/ | ||
- | |||
- | 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, | ||
- | |||
- | 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:// | ||
- | |||
- | The Snowden leak (([[https:// | ||
- | |||
- | Long existing standards should not be modified in incompatible ways unless things are fairly dire. We should remember that the " | ||
- | |||
- | 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.'\\ | ||
- | // | ||
- | |||
- | [[pgpfan: | ||
- | [[em: | ||
pgpfan/no_new_ae.txt · Last modified: 2024/01/29 13:21 by b.walzer