4 ms·

I don't know enough about either the technical nuance or the political drama, but some observers have noted that GnuPG's implementation is (deliberately?) incom

by growse 5mo ago

I don't know enough about either the technical nuance or the political drama, but some observers have noted that GnuPG's implementation is (deliberately?) incompatible with the IETF's standards. It's not clear why. https://floss.social/@hko/116459621169318785 https://floss.social/@hko/116459621169318785

capitol_ 5mo ago
As far as I understood it: GnuPG started to implement stuff from the standard before it was finished, the standard continued to improve and GnuPG refused to change code already written. Combined with some personal drama.
- em-bee 5mo ago
  it's not that simple. the new standard is a complete rewrite of the old one. they are not even compatible anymore. things the old standard used to support are not supported in the new standard. that makes any implementation of the new standard incompatible with implementations of the old one. GnuPG simply refused to stop supporting the old standard and decided to fork the standard itself. on the personal drama my interpretation is that it resulted from people backing the new standard being unhappy that GnuPG didn't go along. my opinion is that rewriting standards like that is the result of design by committee. everyone wants to put their mark on it. designing a new standard is fine, but the new standard should have also received a new name, or it should at least have been acknowledged that the old standard still needs to be supported until enough time has passed that the old standard is no longer in use. (which could take decades if not more if we want to be realistic and consider that encrypted data at rest could linger around pretty much forever unless actively re-encoded.) (source: i talked to a GnuPG developer)
  - singpolyma3 5mo ago
    LibrePGP is also a rewrite. To keep supporting legacy v4 you have to keep having v4 code no matter if the new thing you add is v5 (LibrePGP) or V6 (the RFC)
    - deleted 5mo ago
      [deleted]
    - em-bee 5mo ago
      actually neither are complete rewrites. i played around with diff and found that the new version of OpenPGP seems to keep about 60% of the old one and LibrePGP seems to keep 90%. so the rewrite claim was exaggerated. i didn't compare the stuff that was added or merged.
      - andrewgdotcom 5mo ago
        The claim is even more exaggerated than that, because a lot of the diffs between 4880 and 9580 are editorial and structural, and don't have any semantic effect.
  - andrewgdotcom 5mo ago
    > the new standard is a complete rewrite of the old one. they are not even compatible anymore. My honest first reaction to this statement would get me permabanned from this site, so here’s the polite version: This is nonsense on stilts. It is so ill-informed and baseless I struggle to understand how anyone who has read the RFCs in question could possibly come to this conclusion. It is hooey. > things the old standard used to support are not supported in the new standard. Aside from deprecating some ancient cryptographic algorithms that nobody uses any more, everything from RFC4880 is in RFC9580. Can you point out a concrete example of something (non-obsolete!) that is missing? > that makes any implementation of the new standard incompatible with implementations of the old one. That is news to every openpgp implementation other than gnupg, which have happily implemented both. Even RNP have it in a feature branch somewhere. > (source: i talked to a GnuPG developer) Which one? When? It would genuinely help if they would go on the record. I strongly suspect their actual opinion would differ from what you’ve reported here. There’s enough hearsay nonsense about the schism floating around the internet as it is, without adding to it.
    - em-bee 5mo ago
      i appreciate you making the effort to register an account to make this comment. i have addressed some of the issues raised in a comment here: https://news.ycombinator.com/item?id=48058065 https://news.ycombinator.com/item?id=48058065 i hope you'll notice this reply and get a chance to read it.
upofadown 5mo ago
From the GnuPG prospective RFC-9580 is a deliberate fork away from what agreement could be achieved. Basically the faction that is now called RFC-9580 (mostly Sequoia and Proton) wanted to make a lot of changes to the existing standard but the faction that is now called LibrePGP (mostly GnuPG and RNP) was not convinced that those changes were necessary. Traditionally the OpenPGP standards process has been very conservative and minimalistic. GnuPG comes from that tradition. So the RFC-9580 faction created their own maximalist version of the standard and are actively promoting it as the standard. So from a user perspective, there are two incompatible proposals out there. It's a mess. So it is better to aggressively ignore them both and maintain interoperability by sticking with RFC-4880 (OpenPGP). That might be a problem if you for some reason are still concerned about a quantum attack against cryptography as the post quantum stuff has gotten caught in this schism. It is certainly something that the users need to keep in mind.
- throw0101a 5mo ago
  > […] and are actively promoting it as the standard. Well: > Category: Standards Track * https://datatracker.ietf.org/doc/html/rfc9580 https://datatracker.ietf.org/doc/html/rfc9580
  - tovej 5mo ago
    It is a standard proposal, which is why it's in the standards track. The point was that it is not the only (the) standard, and not the universally accepted one.
    - ekr____ 5mo ago
      A few points about the IETF process: - As a practical matter, anything that is a Proposed Standard RFC is a standard. In principle, there is a two-level system with PS and Internet Standard (down from three levels) but most WGs don't bother to advance specifications past PS. For example, TLS and QUIC are both PS. - RFC 9580 obsoletes RFC 4880, so from the perspective of the IETF, it supersedes it. Of course, this doesn't make people do anything.
  - 5mo ago
woodruffw 5mo ago
> It's not clear why. The situation is farcical, and stems from the double bind that PGP has been in for at least 20 years: the standards are bad and need modernization, but it’s impossible to modernize them because the single thing that retains “serious” users of PGP is backwards compatibility. The end result of this is a version of Weekend at Bernie’s where both GPG and OpenPGP are fighting over how to dress up the corpse, while the rest of the world has moved on.
- Avamander 5mo ago
  > The end result of this is a version of Weekend at Bernie’s where both GPG and OpenPGP are fighting over how to dress up the corpse, while the rest of the world has moved on. Unfortunately there's something akin to a conflict of interest with both RNP and OpenPGP. OpenPGP guys have gpgsm, and RNP people also maintain the S/MIME part in Thunderbird. Both have stagnated and are holding back what would have otherwise moved on.
- upofadown 5mo ago
  PGP covers the case where data is encrypted and might stick around in that state for a long time. Decades. So backwards compatibility is essential. Fortunately we can use the existing standard (RFC-4880) in a way that is completely secure. Remember, we are talking about the standard that was in effect when the Snowden leak revealed that PGP is on a very short list of things the NSA has no access to. There is no reason to think that has changed since then.
  - woodruffw 5mo ago
    I’m sorry, but it’s beyond the domain of serious discourse to assert that RFC 4880 is “completely secure.” This isn’t a position that even die-hard PGP fans take. (As just one small example: the only mandatory symmetric cipher in 4880 is 3DES, and nobody serious is recommending 3DES for long term stored encryption in 2026.)
    - upofadown 5mo ago
      I stated that it was possible to use RFC-4880 in a way that is completely secure, not that every possible use is completely secure. Your example mentions 3DES. 3DES is secure. The reason it is not recommended is because 128 bit block lengths allow longer file/message lengths than 3DES can accommodate on one key. At any rate, RFC-4880 permits the use of AES and that is what is normally used.
Valodim 5mo ago
Short version: Werner Koch personally hates some people involved with the RFC9580 standardization, and cannot emotionally bear working with anything even loosely associated. He also struggled accepting anyone's opinion but his own while editor of the draft back then. Search for "asking the editor to step down" to find the moment when the working group decided he was more trouble than it's worth (and GnuPG's support was obviously worth a lot in the openpgp community).

by growse 5mo ago

capitol_ 5mo ago

As far as I understood it: GnuPG started to implement stuff from the standard before it was finished, the standard continued to improve and GnuPG refused to change code already written. Combined with some personal drama.

em-bee 5mo ago
it's not that simple. the new standard is a complete rewrite of the old one. they are not even compatible anymore. things the old standard used to support are not supported in the new standard. that makes any implementation of the new standard incompatible with implementations of the old one. GnuPG simply refused to stop supporting the old standard and decided to fork the standard itself. on the personal drama my interpretation is that it resulted from people backing the new standard being unhappy that GnuPG didn't go along. my opinion is that rewriting standards like that is the result of design by committee. everyone wants to put their mark on it. designing a new standard is fine, but the new standard should have also received a new name, or it should at least have been acknowledged that the old standard still needs to be supported until enough time has passed that the old standard is no longer in use. (which could take decades if not more if we want to be realistic and consider that encrypted data at rest could linger around pretty much forever unless actively re-encoded.) (source: i talked to a GnuPG developer)
- singpolyma3 5mo ago
  LibrePGP is also a rewrite. To keep supporting legacy v4 you have to keep having v4 code no matter if the new thing you add is v5 (LibrePGP) or V6 (the RFC)
  - deleted 5mo ago
    [deleted]
  - em-bee 5mo ago
    actually neither are complete rewrites. i played around with diff and found that the new version of OpenPGP seems to keep about 60% of the old one and LibrePGP seems to keep 90%. so the rewrite claim was exaggerated. i didn't compare the stuff that was added or merged.
    - andrewgdotcom 5mo ago
      The claim is even more exaggerated than that, because a lot of the diffs between 4880 and 9580 are editorial and structural, and don't have any semantic effect.
- andrewgdotcom 5mo ago
  > the new standard is a complete rewrite of the old one. they are not even compatible anymore. My honest first reaction to this statement would get me permabanned from this site, so here’s the polite version: This is nonsense on stilts. It is so ill-informed and baseless I struggle to understand how anyone who has read the RFCs in question could possibly come to this conclusion. It is hooey. > things the old standard used to support are not supported in the new standard. Aside from deprecating some ancient cryptographic algorithms that nobody uses any more, everything from RFC4880 is in RFC9580. Can you point out a concrete example of something (non-obsolete!) that is missing? > that makes any implementation of the new standard incompatible with implementations of the old one. That is news to every openpgp implementation other than gnupg, which have happily implemented both. Even RNP have it in a feature branch somewhere. > (source: i talked to a GnuPG developer) Which one? When? It would genuinely help if they would go on the record. I strongly suspect their actual opinion would differ from what you’ve reported here. There’s enough hearsay nonsense about the schism floating around the internet as it is, without adding to it.
  - em-bee 5mo ago
    i appreciate you making the effort to register an account to make this comment. i have addressed some of the issues raised in a comment here: https://news.ycombinator.com/item?id=48058065 https://news.ycombinator.com/item?id=48058065 i hope you'll notice this reply and get a chance to read it.

upofadown 5mo ago

From the GnuPG prospective RFC-9580 is a deliberate fork away from what agreement could be achieved. Basically the faction that is now called RFC-9580 (mostly Sequoia and Proton) wanted to make a lot of changes to the existing standard but the faction that is now called LibrePGP (mostly GnuPG and RNP) was not convinced that those changes were necessary. Traditionally the OpenPGP standards process has been very conservative and minimalistic. GnuPG comes from that tradition. So the RFC-9580 faction created their own maximalist version of the standard and are actively promoting it as the standard. So from a user perspective, there are two incompatible proposals out there. It's a mess. So it is better to aggressively ignore them both and maintain interoperability by sticking with RFC-4880 (OpenPGP). That might be a problem if you for some reason are still concerned about a quantum attack against cryptography as the post quantum stuff has gotten caught in this schism. It is certainly something that the users need to keep in mind.

throw0101a 5mo ago
> […] and are actively promoting it as the standard. Well: > Category: Standards Track * https://datatracker.ietf.org/doc/html/rfc9580 https://datatracker.ietf.org/doc/html/rfc9580
- tovej 5mo ago
  It is a standard proposal, which is why it's in the standards track. The point was that it is not the only (the) standard, and not the universally accepted one.
  - ekr____ 5mo ago
    A few points about the IETF process: - As a practical matter, anything that is a Proposed Standard RFC is a standard. In principle, there is a two-level system with PS and Internet Standard (down from three levels) but most WGs don't bother to advance specifications past PS. For example, TLS and QUIC are both PS. - RFC 9580 obsoletes RFC 4880, so from the perspective of the IETF, it supersedes it. Of course, this doesn't make people do anything.
- 5mo ago

woodruffw 5mo ago

> It's not clear why. The situation is farcical, and stems from the double bind that PGP has been in for at least 20 years: the standards are bad and need modernization, but it’s impossible to modernize them because the single thing that retains “serious” users of PGP is backwards compatibility. The end result of this is a version of Weekend at Bernie’s where both GPG and OpenPGP are fighting over how to dress up the corpse, while the rest of the world has moved on.

Avamander 5mo ago
> The end result of this is a version of Weekend at Bernie’s where both GPG and OpenPGP are fighting over how to dress up the corpse, while the rest of the world has moved on. Unfortunately there's something akin to a conflict of interest with both RNP and OpenPGP. OpenPGP guys have gpgsm, and RNP people also maintain the S/MIME part in Thunderbird. Both have stagnated and are holding back what would have otherwise moved on.
upofadown 5mo ago
PGP covers the case where data is encrypted and might stick around in that state for a long time. Decades. So backwards compatibility is essential. Fortunately we can use the existing standard (RFC-4880) in a way that is completely secure. Remember, we are talking about the standard that was in effect when the Snowden leak revealed that PGP is on a very short list of things the NSA has no access to. There is no reason to think that has changed since then.
- woodruffw 5mo ago
  I’m sorry, but it’s beyond the domain of serious discourse to assert that RFC 4880 is “completely secure.” This isn’t a position that even die-hard PGP fans take. (As just one small example: the only mandatory symmetric cipher in 4880 is 3DES, and nobody serious is recommending 3DES for long term stored encryption in 2026.)
  - upofadown 5mo ago
    I stated that it was possible to use RFC-4880 in a way that is completely secure, not that every possible use is completely secure. Your example mentions 3DES. 3DES is secure. The reason it is not recommended is because 128 bit block lengths allow longer file/message lengths than 3DES can accommodate on one key. At any rate, RFC-4880 permits the use of AES and that is what is normally used.

Valodim 5mo ago

Short version: Werner Koch personally hates some people involved with the RFC9580 standardization, and cannot emotionally bear working with anything even loosely associated. He also struggled accepting anyone's opinion but his own while editor of the draft back then. Search for "asking the editor to step down" to find the moment when the working group decided he was more trouble than it's worth (and GnuPG's support was obviously worth a lot in the openpgp community).