LibrePGP is an alternative, updated specification of the
OpenPGP encryption standard. It was developed as a
response to changes made to the OpenPGP specification by
a subgroup within the IETF OpenPGP working group.
These changes were perceived as disruptive to the existing
implementations, raising concerns about
interoperability and security.

LibrePGP wants to preserve the core principles of
openness and compatibility:

  • Long-term Stability:
    LibrePGP ensures reliable encryption with decades in mind.
  • Critical
    LibrePGP is designed
    for KRITIS,
    NGOs, journalist, public administration, …
  • Compatibilty: LibrePGP
    stands for a stable protocol where implementors can rely upon.
  • Real-world Focus: Everyday security concerns over academic ones.

Learn More

Software with LibrePGP support

Given that the majority of email clients and related software rely
on GnuPG or RNP

we anticipate no compatibility issues for users.

A Critique on the OpenPGP Updates

The IETF OpenPGP Working Group (WG) at some point
decided to give up on its charter to produce an
updated specification and instead started to re-invent
that standard. Whether this is in line with IETF
rules is questionable.

Considering that new features and discussions for larger
updates of the specification delayed a new RFC for
many years and were the reason for closing the WG in
2017 and re-opening in 2020, we proposed to go back to
the last commonly agreed upon draft or to conclude the
WG on the grounds that no rough consensus could be

01 Symmetric Mode

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).

02 Padding Packet

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.

03 Changes to the ECDH Encryption

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.

04 Proliferation for Algorithms

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.

05 Removal of Useful Real-world Features

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.

06 Removal of Security Fixes

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.

07 Salted Signature Issue

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).

08 Regression from Deployed Formats and Standard Behavior

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.

  • 1996-08

  • 1997-11

  • 1997-12

    First release of GnuPG, compatible to PGP

  • 2007-11

  • 2015

    Work on rfc4880bis with V5 key format and OCB mode starts.

  • 2018-01

    Working code in RNP.

  • 2018-02

    Working code in GnuPG 2.3.

  • 2020-07

    GnuPG 2.2 has been released, featuring a backported version of the V5 key format.

  • 2021-09

    Consensus on RFC 4880bis draft, only editorial things needed to be finalized.

  • 2021-10 to present

    A small group initiated a significant revision of the RFC, setting aside previous efforts. This included the introduction of a new key format, removal of the V5 key format, and incompatible changes to OCB.

  • 2023-11

    LibrePGP: based on the latest consensus, working code, and the V5 format in use.


LibrePGP is supported by the following Open Source


GnuPG allows you to encrypt and sign your data and
communications; it features a versatile key management
system, along with access modules for all kinds of
public key directories. GnuPG, also known as GPG, is a
command line tool with features for easy integration
with other applications.

Since 1998 GnuPG provides end-to-end encryption on a
wide range of platforms.
It is the workhorse of the internet for data and mail encryption,
as well as for signing software repositories.
Select versions of GnuPG are also sanctioned and extensively utilized for


RNP is a set of openly-licensed OpenPGP tools that
works on all major platforms, including Windows,
macOS, Linux and *BSD. This includes the
executables rnp for handling OpenPGP data
and rnpkeys for key
management. librnp is the core library
used for all OpenPGP functions.

Since 2019 RNP provides the OpenPGP functionality for the
Mozilla Thunderbird
mail client. Thunderbird is available for all common
computing platforms like macOS, Linux, *BSD, and Windows.


Gpg4win (GNU Privacy Guard for Windows) enables
users to securely transport emails and files with the
help of encryption and digital signatures through an
easy to use user interface. Encryption
protects the contents against an unwanted party
reading it. Digital signatures make sure that it was
not modified and comes from a specific sender.

Since its inception more than 18 years ago Gpg4win is
the de-facto standard to use LibrePGP on Windows. It
used by journalists, activists and companies all over
the world.

Join us

Want to stay in touch or learn more? Join the discussion! Subscribe to our mailing list for the latest updates and news.

Read More