This is a short writeup about a new feature in the rsop CLI tool:

Since version 0.8.0, rsop can decrypt a GnuPG-proprietary message encryption format.

GnuPG sometimes produces non-standard encrypted messages #

Unfortunately, under some circumstances, GnuPG produces encrypted messages that are not compatible with the OpenPGP standard. This issue started in its 2.4.x series. GnuPG calls its proprietary format “OCB encrypted data”.

However, note that practically all big Linux distributions disable these GnuPG non-standard formats in their versions of the GnuPG package by default. So on most Linux distributions, if you follow along with the CLI calls in this article, you will end up producing a standard OpenPGP encrypted message (and not the problematic format I’m demonstrating here). Windows users of GnuPG on the other hand will usually use upstream GnuPG, without these safeguards!

So just for this blog article, I’m using GnuPG as distributed by the upstream project, without the proprietary edges removed.

(To be clear: usually I’m very happy that my distribution is giving me a cleaned up version of GnuPG that only produces OpenPGP-conformant artifacts. But for this article, I specifically want to produce a non-standard encrypted message for demonstration purposes).

Making a test key #

With all of that said, let’s make an GnuPG-proprietary encrypted test-message. First, we’ll make a new key for our test user “alice”:

$ gpg --quick-generate-key alice

pub   ed25519 2025-09-25 [SC] [expires: 2028-09-24]
      0D2C76C91726A58B0490B7E790D316AE474F721C
uid                      alice
sub   cv25519 2025-09-25 [E]

This key will advertise in its preferences that it is willing to receive GnuPG’s proprietary encryption format. So when we encrypt a message to it, using upstream GnuPG, GnuPG will see that preference and produce its own “OCB encrypted data” format.

Encrypting a message #

So now let’s encrypt a message to Alice:

$ echo "foo" | gpg -a -e -r alice > gnupg-encrypted.msg

$ cat gnupg-encrypted.msg

-----BEGIN PGP MESSAGE-----

hF4DW2LC4FrRgf4SAQdAr/nU+qnuNgUYxWNgV/48dbBCZKqUp6mmWl+ORMCg7hgw
yHjVHsO99eY9gGkLnFQGeGosbZE636erDB0i8ZlVrA3q3RCcFBJBWDpVYjmgFIi8
1EkBCQIQUZTtPscECqnaR93GkUxyXm1uZXgJVyJAj/oGE6TJlSppaSgBNxI+aJG4
2MedfwHRm5HgZ3qR9EohwZv/f7+HYzpNxKcT
=QBMW
-----END PGP MESSAGE-----

With upstream GnuPG version 2.4.x (or newer), this will have produced a GnuPG-proprietary encrypted message format.

Inspecting the internals of the encrypted message #

We can ask GnuPG to show us the internal structure of the encrypted message, to see which encryption format the message uses:

$ gpg --list-packets gnupg-encrypted.msg
# off=0 ctb=84 tag=1 hlen=2 plen=94
:pubkey enc packet: version 3, algo 18, keyid 5B62C2E05AD181FE
	data: [263 bits]
	data: [392 bits]
# off=96 ctb=d4 tag=20 hlen=2 plen=73 new-ctb
:aead encrypted packet: cipher=9 aead=2 cb=16
	length: 73

I’ll say that I find this debug output pretty hard to read, but we’re really only looking for one number (so we’ll be ok).

The last three lines represent the encrypted data container. In the first line of that block, tag=20 shows that this is indeed the GnuPG-proprietary “OCB Encrypted Data Packet” (which GnuPG also refers to as “aead encrypted packet” in the following line).

Based on this packet type “20”, we know that the message uses GnuPG’s proprietary format.

(By contrast, in standard OpenPGP, modern encrypted messages always use the Symmetrically Encrypted and Integrity Protected (SEIPD) Data Packet type, which has id “18”.)

Decrypting GnuPG’s proprietary encryption format with rsop #

To decrypt this message outside of GnuPG, we export Alice’s private key material from GnuPG’s keystore, and store it in the file alice.tsk (as an OpenPGP transferable secret key):

$ gpg --export-secret-key -a alice > alice.tsk

Starting with rsop version 0.8.0, non-standard GnuPG “OCB” encrypted messages can be decrypted just like regular OpenPGP encrypted data:

$ cat gnupg-encrypted.msg | rsop decrypt alice.tsk
foo

Why support decryption of this format? #

While I generally think it’s best to stick to the IETF standardized OpenPGP formats, and ignore any proprietary extensions, some users may inadvertently have received encrypted messages that use GnuPG’s “OCB” format.

If those users are happy with GnuPG, then more power to them. However, if they want to migrate to different software (e.g. by basing their PGP usage on standardized SOP tools), then it may be relevant for them to be able to decrypt their existing corpus of messages.

With this new rsop feature, users have one more building block that enables them to move away from GnuPG without losing access to their message contents.