About the "OpenPGP Schism"
articles.59.ca
articles.59.ca
Then, some changes were made to how the AEAD modes (OCB, GCM, and EAX) are used, particularly to provide key separation between the various modes. In the old version, or what is now called "LibrePGP", the same session key can/could be used with different AEAD modes, and - if any of the AEAD modes turns out to be secure - a downgrade attack is possible. Furthermore, a downgrade attack from AEAD to non-AEAD could potentially be possible (à la [1]). All of that has been completely prevented in the crypto refresh, which indeed required a change in how AEAD is used.
However, it's GnuPG's choice not to implement those changes, not the IETF working group's choice to make changes, that caused this rift. IETF drafts change all the time, and in fact should change, in the face of possible security issues.
Note that v5, and the "LibrePGP" flavor of AEAD, has not been specified in an RFC (so far). Normally, it's a bad idea to generate messages according to a draft. GnuPG has done so, and now they're stuck with having to support it. Now, writing an RFC to describe that older format is also fine, but none of this should've caused a rift, and blaming that on the crypto refresh is silly.
---
Regarding EAX, it was discussed a couple times to remove it but some people wanted to keep it, so it was kept - as optional to implement. This shouldn't cause any implementation burden on those who don't want to implement it, and those who do want to use it can. I do agree it's a bit inelegant to have three AEAD modes in the spec, but again, it shouldn't cause any issues.
[1]: https://www.ndss-symposium.org/wp-content/uploads/2017/09/10...
The security community are right to be skeptical of changes such as this, the NSA has shown time and time again to have influenced design and standardization processes for their own benefit, it’s always been under the premise of “oh this makes things more secure” and it does superficially, then a decade later someone figures out we got had, again.
So standards are great, security standards are important, but the freedom to be skeptical about why and who are driving changes and just going your own way until it’s clear, that’s paramount.
That seems like a red herring, at least if taken out of the context of this thread. OCB mode is already supported by GnuPG and had been added to the draft RFC before GCM was added. Werner has argued that there should only be a single AEAD mode, OCB, to simplify everything, including interoperability. But-for patent issues, GCM likely never would have existed; OCB is at least as secure, simpler, and substantially more performant. If one of OCB, GCM, or EAX turns out to be meaningfully less secure than the others, it's unlikely to be OCB.
I personally actually also agree that having a single mode would've been more elegant, but sometimes, in a collaborative open standard, compromises are necessary for practical or political reasons. Some people care about FIPS compliance, others care about performance, and so on. If you have a benevolent dictator, you can just tell (some of) those people to go away, but that's not really how an IETF working group works - the goal there is (rough) consensus.
And, personally I don't think any of these compromises are so unreasonable as to call for fearmongering and references to the NSA. Again, GCM is used securely in lots of places, there's no reason it can't be used securely in OpenPGP too.
Is the current RFC-4880 approved by NIST?
>...the same session key can/could be used with different AEAD modes, ...
How would this be possible in practice?
>...a downgrade attack is possible.
For the medium in question, where a message/file is encrypted and then flung off into the either, how would any sort of downgrade attack be possible.
> ...à la [1]...
That reference is about an entirely different sort of medium, specifically what part of the paper is relevant here?
I was mostly arguing against the part of the article that said:
> Unfortunately, the Crypto Refresh Current faction has deliberately made their version incompatible with the GnuPG version. It is not clear to me why they did this.
I tried to explain that the first half of that is not true, and tried to explain the reasoning behind the changes for the second part.
Then, to the more general question of the purpose of the crypto refresh vs RFC4880; the goal was to modernize the cryptography in use, to make it more secure and more efficient.
But, note that the crypto refresh also (more or less) suggests what you're saying: when communicating with an implementation that doesn't support the new AEAD modes, CFB mode can still be used.
So - in other words: the crypto refresh is fully backwards-compatible with RFC4880. So it doesn't intend to, nor should it, break compatibility with GnuPG. The only risk of incompatibility is with messages or keys generated by GnuPG that don't comply with RFC4880 or any other RFC (at the moment).
"LibrePGP" could still become an RFC, though, at which point other implementations could also implement it (in fact, some already do, behind a feature flag), and all of the incompatibilities would fully go away (if GnuPG also implements the crypto refresh). And in fact, that's what I've been advocating for: for everybody to implement both. While it's technically not the nicest solution, it's the most straightforward way to heal this "schism" (that shouldn't have been a schism in the first place, just a technical disagreement).
---
> Is the current RFC-4880 approved by NIST?
It's possible to use a FIPS-compliant subset of RFC4880, that only uses NIST-approved algorithms, yes. GnuPG even supports this [1]. LibrePGP does not have a FIPS-compliant AEAD mode, so I assume that it'd have to fall back to CFB in FIPS mode. But some people want to use AEAD and be FIPS-compliant, hence why GCM was added.
> For the medium in question, where a message/file is encrypted and then flung off into the either, how would any sort of downgrade attack be possible.
Similar to the EFAIL attacks [2], where a downgrade attack from authenticated CFB to unauthenticated CFB caused concrete issues, a downgrade attack from AEAD to CFB could cause issues as well, if a security issue was found with the latter. Even if you think that's unlikely, the security of AEAD modes shouldn't depend on the security of CFB mode.
[1]: https://www.gnupg.org/documentation/manuals/gcrypt/Enabling-...
[2]: https://efail.de/
>...the goal was to modernize the cryptography in use, to make it more secure and more efficient.
Where was this goal written down? Anyway, as a user, I want secure. I don't care that much about efficiency. I absolutely don't care that someone thinks some methods are more "modern" than others. I really really want an actual standard. Not a whole bunch of pointless incompatibility.
There were no downgrade attacks demonstrated as part of EFAIL. In fact, the researchers were not able to compromise the current OpenPGP OCFB-MDC authenticated encryption mode at all. They were reduced to listing implementations that did not handle HTML link injection in the way that they preferred.
>...the security of AEAD modes shouldn't depend on the security of CFB mode.
OCFB-MDC is an athenticated encryption mode. A particularly simple and straightforward one. No other modes are required. That is the point I am trying to make here.
https://datatracker.ietf.org/doc/charter-ietf-openpgp/03/
> Anyway, as a user, I want secure. I don't care that much about efficiency. I absolutely don't care that someone thinks some methods are more "modern" than others.
There are plenty of security improvements in the crypto refresh, see https://proton.me/blog/openpgp-crypto-refresh.
Also, I don't want to be rude here but the OpenPGP Working Group is not obligated to do only what you want and nothing else. A charter was agreed upon, and followed.
> I really really want an actual standard. Not a whole bunch of pointless incompatibility.
A new RFC is about to be released, updating the standard. It shouldn't cause any incompatibility, as I've tried to explain three different ways.
> OCFB-MDC is an athenticated encryption mode. A particularly simple and straightforward one. No other modes are required. That is the point I am trying to make here.
But is it secure? We don't really know because there's no security proof. It also uses SHA-1, which might be fine or might not be.
The maintainers of all OpenPGP implementations (including GnuPG) saw value in adopting AEAD modes. Clearly there was some disagreement in which modes should be used and how. None of this should be cause to fork the standard entirely, though. And it also shouldn't be cause to give up entirely and throw away everything except RFC4880.
For those that want to implement and use AEAD, they can. Those that don't want to, don't have to. Again, none of this should cause incompatibilities, so there's no real reason to even argue about it on the internet and blame the crypto refresh for doing so :) For you as a user, it should be invisible. If it isn't, then the implementation is doing something wrong, not the spec.
>But is it secure?
No reasonable person would think otherwise. It has withstood scrutiny for 20+ years.
>We don't really know because there's no security proof.
Why would we need a separate proof? The principles behind this sort of construct are pretty well known by now. See:
* https://cseweb.ucsd.edu/~mihir/papers/enc-red.pdf
>It also uses SHA-1, which might be fine or might not be.
Yeah it is for this sort of approach. That is not in question.
At any rate, no one has any obligation to prove that OCFB-MDC is secure. It falls to those who that it be superseded to prove that there is something wrong with it. You (or I) can't legitimately suggest that something be replaced simply because you (or I) don't understand how it works.
>For you as a user, it should be invisible.
A significant portion of the article explains why it is not invisible, as in problems being caused right now with a list of examples and everything.