LibrePGP

It seems that this new scheme was introduced for the benefit of allowing GCM as yet another encryption mode. GCM is a counter mode and, as can be seen by the large changes required, is hard to get right. Meanwhile we have GCM in CMS (the core of S/MIME) because Microsoft decided to go this way. However, OpenPGP has made its decisions based on technical soundness and not based on larger vendor, government, or committee decision.

The WG once decided to go with OCB and EAX. EAX was only added to avoid possible patent problems. However, in the 4.5 years since the introduction of EAX, the OCB patent expired. Thus, there is no more reason to reject OCB, and it should be declared as a RECOMMENDED mode with the intention to make it a MUST mode in some future OpenPGP. It can also be expected that FIPS-140 will eventually allow OCB.

Our suggestion was: Drop all the new AEAD ideas and use what has been deployed and agreed upon in the OpenPGP WG a long time ago. Further, turn OCB into MUST WG a long time ago. Further, turn OCB into MUST and EAX into MAY (only for backward compatibility with deployed implementations).

A padding packet is introduced with the idea to mitigate traffic analysis. However, it is suggested to use random data for the content of this packet and thus this packet opens a huge covert channel. This is especially concerning for institutional users efforts regarding Data Leak Prevention (DLP). Suggestions to use padding based on a verifiable seed, were rejected despite that this is the standard method to do padding.

This padding idea has come up in discussion every once in a while over the last 25 years and has always been rejected because it does not belong into the encryption layer but into the application (plaintext) layer.

ECDH is the standard way to do encryption with elliptic curves. For OpenPGP ECDH has been specified in RFC-6637 from 2012 and been implemented by PGP and GnuPG even a year earlier. Instead of keeping this solid specification some details have been changed without a sound reason.

The new draft not only allow the use of GCM as a third encryption mode but adds a couple of other required algorithms:

• HKDF
• Argon2
• Optional modes (EAX, OCB, GCM, and a way to define even more)

Werner Koch joined the AES conference in 2000 on Phil Zimmermann's wish to talk about algorithm proliferation. They agreed on pushing the forthcoming AES along with their MDC extension, get Twofish and so out of the focus, and in general resist to add new algorithms. That is for the simple reason that neither PGP nor GnuPG wanted to maintain all new algorithms until eternity.

Later, they had to do a political compromise to allow Camellia for the use in Japan and Brainpool curves for European use. We should really stick to this and not support algorithms which are just a substitute for existing crypto building blocks. Since added complexity makes a review harder and the larger codebase has to be maintained indefinitely for backwards compatibility.

For example, in 2016 an m flag was introduced to indicate that the plaintext shall be interpreted as MIME data. This has been removed along with deprecating the traditional t flag to distinguish between binary and text data. Having the ability to easily detect MIME data is for example required to process attachments from web mail clients or in air-gaped environments.

The designated revoker feature has also been deprecated with the rationale that a better method is to achieve this with an "escrowed" revocation, pre-created by the user. In fact, GnuPG creates such a revocation certificate since version 2.1 (released in 2014), to mitigate the common problem of a forgotten password. But this is not a replacement for corporate needs: the designated revoker is an important feature to manage a large scale deployments of OpenPGP keys and acts as a CRL (certificate revocation list) replacement.

Due to an implementation bug in PGP 5, the metadata of a signed file was not covered by the signatures. RFC-4880 didn't fix that for backward compatibility. However, users were often surprised when they learned that the shown filename and file data could be changed while keeping the signature intact. With the introduction of the new v5 signature packet format, the opportunity to fix that was taken.

However, the crypto-refresh group then introduced v6 signatures and removed the fix (see this commit) with the flimsy explanation that the way to populate that the field is not clear in a theoretical encrypt-then-sign scenario and that signatures could not be detached and reattached (which is obvioulsy wrong). A later proposed fix for v4 signature packets (Meta Hash subpacket, see discussion) was not considered.

Salted signature were introduced with the idea that they might mitigate a chosen prefix attack in the same way as they will do for a certain SHA-1 based Web-of-Trust attack. No research for that statement has been cited just an assumption and a concern related to fault attacks on EdDSA which is about the development of Wireguard-like protocol. However, such fault attacks can be more securely detected by checking the signature after verification in the same way as the mitigation to Lenstra's attack on RSA's CRT.

Anyway, the major concern here is that this adds another 32 octet covert channel to each message (and also blow the signature up by 64 octets) In this case it is not an optional feature as with the padding packet. This is a clear violation of best current practices in sensitive areas where signed mails are mandatory and encryption is not enforced (or monitored by a gateway).

In general the crypto-refresh draft tends to ignore the requirements of long term storage needs and considers online communication and software deployment pattern as the major OpenPGP usage. Data and software life-cycle management has not been adequately taken in consideration and thus the draft regresses heavily from 30 years of PGP history.