Re: Adding a nonce before hashing as covert channel

Andrew Gallagher via Gnupg-devel <[email protected]> Wed, 18 Dec 2024 11:30:17 +0000
Newsgroups	gmane.comp.encryption.gpg.devel
Message-ID	<[email protected]>
On 18 Dec 2024, at 09:07, Werner Koch via Gnupg-devel <[email protected]> wrote:
> 
> It then got stuck by people who
> wanted to completely overhaul the spec and do an OpenPGP 2.

Anyone who has worked with OpenPGP for any length of time and who doesn’t have a burning desire to completely overhaul the spec IMO hasn’t been paying attention. Yes, some of the newer implementations have got it wrong at times. But you either find some imperfect way to work with the youngsters and their new-fangled ideas, or they will ignore you and leave you behind. That’s the great, timeless tragedy of existence.

> Search the
> WG ML for this (sometime around 2017/2018).  The end result of the WG is
> an extensive rework of the specification and not the planned move to
> newer algorithms (SHA-2, Modern AE) and integration of the ECC RFC.

It’s true that crypto-refresh performed a significant overhaul of the *structure* of the document, which does make detailed comparisons more difficult than perhaps they could have been. But the end result of the WG *was* the planned move to newer algorithms, and it *did not* extensively rework the semantics.

For the record, there’s a great (if slightly outdated) summary of the non-editorial differences between “crypto-refresh” (now RFC9580) and “rfc4880-bis” (now LibrePGP) here:

https://mailarchive.ietf.org/arch/msg/openpgp/aqBy97lj2P4DVxTds0eKZDVdmms/

NB at the time of writing, both crypto-refresh and rfc4880bis specified conflicting “v5” formats. To fix the ambiguity, crypto-refresh's v5 => RFC9580’s v6. In addition, both specs have since adopted some ideas from each other, so the differences are not as great as the above summary suggests.

The fundamental incompatibility between the two specifications is not technical. The irreconcilable difference is that one person has a veto over LibrePGP, but nobody has a veto in the IETF WG. Most implementors consider this a positive development.

>> forward is for you to continue to evolve rfc4880bis (now under your
>> new "LibrePGP" banner).
> 
> Not mine.  LibrePGP is a specification agred upon by the major real
> world implementations.

LibrePGP is a specification agreed upon by *two* implementations. If you arbitrarily include RNP (i.e. Thunderbird) but not openpgp.js (i.e. Protonmail, Mailvelope, FlowCrypt) in the “major real world implementation” category then I’m not sure what else to say.

A

_______________________________________________
Gnupg-devel mailing list
[email protected]
https://lists.gnupg.org/mailman/listinfo/gnupg-devel
signature.asc (application/pgp-signature, 833 B)