4 ms·

> My article was ultimately arguing that we could just continue using the current OpenPGP standardized OCFB-MDC mode indefinitely without undue risk. So it wou

by twiss 3y ago

> My article was ultimately arguing that we could just continue using the current OpenPGP standardized OCFB-MDC mode indefinitely without undue risk. So it would probable be more valid (and probably easier) to argue against that directly. I don't see the point of arguing about what GnuPG is doing. 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-FIPS-mode.html https://www.gnupg.org/documentation/manuals/gcrypt/Enabling-... [2]: https://efail.de/ https://efail.de/

upofadown 3y ago
This is wandering all over the place... >...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.
- twiss 3y ago
  > Where was this goal written down? https://datatracker.ietf.org/doc/charter-ietf-openpgp/03/ 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 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.

by twiss 3y ago

upofadown 3y ago

This is wandering all over the place... >...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.

twiss 3y ago
> Where was this goal written down? https://datatracker.ietf.org/doc/charter-ietf-openpgp/03/ 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 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.