5 ms·

The primary reason for adding GCM to the crypto refresh was not efficiency, but rather FIPS compliance (as GCM is the only AEAD mode specified by NIST). Then,

by twiss 3y ago

The primary reason for adding GCM to the crypto refresh was not efficiency, but rather FIPS compliance (as GCM is the only AEAD mode specified by NIST). 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_4_0.pdf https://www.ndss-symposium.org/wp-content/uploads/2017/09/10...

upofadown 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. 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?
- 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/
fieldcny 3y ago
I know quite literally nothing about this situation, but I will offer one comment, which may or may not even be relevant. 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.
- twiss 3y ago
  NIST is not the same organization as the NSA, though. And GCM was not designed by either - it was merely submitted to NIST as a proposal, which was accepted. It has been widely scrutinized, and there's a security proof available, which is more than can be said for CFB+MDC mode. So - of course everyone should feel free to be skeptical, but ideally one should be equally skeptical about the status quo and new proposals :)
  - wahern 3y ago
    > which is more than can be said for CFB+MDC mode 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.
    - twiss 3y ago
      Well - sure, but we can't change the history, and GCM is the mode that got picked by NIST, is most widely implemented, and is used in lots of places. It has been widely analyzed and scrutinized, and is unlikely to turn out to be insecure at this point. 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.

by twiss 3y ago

upofadown 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. 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?

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/

fieldcny 3y ago

I know quite literally nothing about this situation, but I will offer one comment, which may or may not even be relevant. 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.

twiss 3y ago
NIST is not the same organization as the NSA, though. And GCM was not designed by either - it was merely submitted to NIST as a proposal, which was accepted. It has been widely scrutinized, and there's a security proof available, which is more than can be said for CFB+MDC mode. So - of course everyone should feel free to be skeptical, but ideally one should be equally skeptical about the status quo and new proposals :)
- wahern 3y ago
  > which is more than can be said for CFB+MDC mode 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.
  - twiss 3y ago
    Well - sure, but we can't change the history, and GCM is the mode that got picked by NIST, is most widely implemented, and is used in lots of places. It has been widely analyzed and scrutinized, and is unlikely to turn out to be insecure at this point. 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.