The Call of the Open Sidewalk - pgpfan

Keys.openpgp.org Breaks Your Keys

b.walzer@undisclosed.example.com (b.walzer) — Tue, 05 May 2026 21:12:11 +0000

Keys.openpgp.org Breaks Your Keys

This article will be presented in the form of a rant…

Keys.openpgp.org is a PGP keyserver on the internet. It's somewhat popular and is the default keyserver for more than one PGP implementation. That's all the context I am going to provide at this point. Let's generate a key and upload it. This is how GnuPG described it after generation:

pub   rsa2048 2025-11-04 [SC] [expires: 2025-11-18]
      82324300137C02E89D05413CC39BEC8A642ED98D
uid                      Test Key <tk@59.ca>
sub   rsa2048 2025-11-04 [E] [expires: 2025-11-18]

I am not a big fan of routine expiry dates on PGP keys, but since this was a test I thought it would be polite to make an exception. After generation I added a third party signature. I used pgpdump to reveal the structure of the key which I have condensed to:

Public Certification Key
User ID (“Test Key tk@59.ca”)
Signature/Preferences (binds user ID and user preferences to the Public Certification Key)
Signature (third party signature)
Public Encryption Subkey
Signature (binds Public Encryption Subkey to the Public Certification Key)

So a public key used for certifications and signing, a public key used for encryption and some signatures to bind the key together and prevent malicious modifications. The user preferences are also bound to the rest of the key so your correspondents can be sure that they are truly what you prefer. The key contains everything needed for secure end to end encryption and signature verification.

I then uploaded the key to keys.openpgp.org:

You uploaded the key 82324300137C02E89D05413CC39BEC8A642ED98D.

This key is now published with only non-identity information. (What does this mean?)

To make the key available for search by email address, you can verify it belongs to you:
            ┌───────────────────────┐
tk@59.ca    │Send Verification Email│
            └───────────────────────┘
Note: Some providers delay emails for up to 15 minutes to prevent spam. Please be patient.

I deliberately did not click on the “Send Verification Email” button and then downloaded the key from the server. This is what I got after I dumped it:

Public Certification Key
Public Encryption Subkey
Signature (binds Public Encryption Subkey to Public Certification Key)

Three sections had gone missing. I will talk about the third party signature later. Here is the raw pgpdump of the other two missing sections:

Old: User ID Packet(tag 13)(19 bytes)
        User ID - Test Key <tk@59.ca>
Old: Signature Packet(tag 2)(343 bytes)
        Ver 4 - new
        Sig type - Positive certification of a User ID and Public Key packet(0x13).
        Pub alg - RSA Encrypt or Sign(pub 1)
        Hash alg - SHA256(hash 8)
        Hashed Sub: issuer fingerprint(sub 33)(21 bytes)
         v4 -   Fingerprint - 82 32 43 00 13 7c 02 e8 9d 05 41 3c c3 9b ec 8a 64 2e d9 8d 
        Hashed Sub: signature creation time(sub 2)(4 bytes)
                Time - Tue Nov  4 17:50:57 CST 2025
        Hashed Sub: key flags(sub 27)(1 bytes)
                Flag - This key may be used to certify other keys
                Flag - This key may be used to sign data
        Hashed Sub: key expiration time(sub 9)(4 bytes)
                Time - Tue Nov 18 17:50:57 CST 2025
        Hashed Sub: preferred symmetric algorithms(sub 11)(4 bytes)
                Sym alg - AES with 256-bit key(sym 9)
                Sym alg - AES with 192-bit key(sym 8)
                Sym alg - AES with 128-bit key(sym 7)
                Sym alg - Triple-DES(sym 2)
        Hashed Sub: preferred_aead_algorithms(sub 34)(1 bytes)
                AEAD alg - OCB(aead 2)
        Hashed Sub: preferred hash algorithms(sub 21)(5 bytes)
                Hash alg - SHA512(hash 10)
                Hash alg - SHA384(hash 9)
                Hash alg - SHA256(hash 8)
                Hash alg - SHA224(hash 11)
                Hash alg - SHA1(hash 2)
        Hashed Sub: preferred compression algorithms(sub 22)(3 bytes)
                Comp alg - ZLIB <RFC1950>(comp 2)
                Comp alg - BZip2(comp 3)
                Comp alg - ZIP <RFC1951>(comp 1)
        Hashed Sub: features(sub 30)(1 bytes)
                Flag - Modification detection (packets 18 and 19)
        Hashed Sub: key server preferences(sub 23)(1 bytes)
                Flag - No-modify
        Sub: issuer key ID(sub 16)(8 bytes)
                Key ID - 0xC39BEC8A642ED98D
        Hash left 2 bytes - af fc 
        RSA m^d mod n(2041 bits) - ...
                -> PKCS-1

Because we did not choose to verify the associated email address (“tk@59.ca”), the server has chosen to omit the User ID Packet for a reason discussed later. But what about all that other stuff? It's basically collateral damage.

The signature binds the Public Certification Key, the User ID and the preferences together. If you remove the User ID that breaks the signature and thus the binding. So the preferences are invalid and the key is considered damaged. The solution implemented by keys.openpgp.org is to get rid of the whole Signature/Preferences section.

An incomplete list of what we have lost:

signature creation time: When the Preferences and User ID were created or last modified.
key expiration time: When the Certification Key expires. i.e. when the entire key expires.
preferred symmetric algorithms: List of supported encryption algorithms from most preferred to least preferred.
preferred hash algorithms: List of supported hash algorithms from most preferred to least preferred.
features: List of supported cryptographically significant features. e.g. the integrity protected cipher mode.

So… There are some security related preferences in there related to cryptographic choices and some other significant values. Omitting those does not sound like a good idea to me. This might cause you to wonder how cryptographic preferences can be so easily modified under the OpenPGP standard. That is normally something you want to prevent. The short answer is that they actually can't be modified. This is what happened when I attempted to import the key from keys.openpgp.org using GnuPG:

gpg --import tk_unverified_signed.asc                                                                    
gpg: key C39BEC8A642ED98D: no user ID

GnuPG straight up refuses to import the key because it has no User ID. That's because the OpenPGP standard (RFC-4880) says:

11.1.  Transferable Public Keys

   OpenPGP users may transfer public keys.  The essential elements of a
   transferable public key are as follows:

     - One Public-Key packet

     - Zero or more revocation signatures

     - One or more User ID packets

     - After each User ID packet, zero or more Signature packets
       (certifications)

     ⋮

So you require at least one User ID. You don't actually require a Signature/Preferences packet (“Signature packets” in the standard) but an unsigned User ID that might have been added by an attacker is insecure and effectively invalid for a key import. GnuPG for example rejects unsigned User IDs by default on an import. It is a bit roundabout, but the preferences are effectively secure in OpenPGP and the key that keys.openpgp.org gave us is invalid.

So keys.openpgp.org breaks your cryptographic preferences…

I then attempted to do the email verification. I could not find out how to do that after I had missed the chance to click the “Send Verification Email” button. I ended up having to reupload the key and then clicked on the “Send Verification Email” button. I was sent a link to the email address in the User ID which I in turn clicked. That resulted in this message:

Your key 82324300137C02E89D05413CC39BEC8A642ED98D is now published for the identity tk@59.ca.

… and the key downloaded from the server had this structure:

Public Certification Key
User ID (“Test Key tk@59.ca”)
Signature/Preferences (binds user ID and user preferences to Public Certification Key)
Public Encryption Subkey
Signature (binds Public Encryption Subkey to Public Certification Key)

So a perfectly usable key but with the third party signature missing.

Just to complete the normal key life-cycle I marked the key revoked with the appropriate certificate and uploaded it:

You uploaded the key 82324300137C02E89D05413CC39BEC8A642ED98D.

This key is revoked.

It is published without identity information and can't be made available for search by email address.

The resulting structure:

Public Certification Key
Signature (revocation)
Public Encryption Subkey
Signature (binds Public Encryption Subkey to Public Certification Key)

As with the key that was not email verified, this key does not seem to be usable either due to a lack of User ID. There is no way to fix this because email verification is not offered for revocations.

Normally you can mark a User ID as revoked when your email and/or name changes. Since keys.openpgp.org deletes the User ID on a revocation, this is not possible.

So keys.openpgp.net also breaks your revocations…

Why is keys.openpgp.org deleting parts of your keys?

User ID and Cryptography Preferences and Others

Keys.openpgp.org is deleting the User ID and the Cryptography Preferences and the rest because of a fear of a European privacy law called the General Data Protection Regulation (GDPR). This discussion ended up being interesting enough to merit a separate article:

When the GDPR Seems to Prevent an Entire Technology

The short version is that the GDPR includes a “Right to Erasure” provision. Traditional PGP keyservers (e.g. the SKS network) are append-only by nature and can not support erasure, only revocation. The idea is that deleting the User ID containing the name and the email address prevents the GDPR from applying to the remaining PGP key.

The User ID is just a convenient handle for the key. The primary identity of a PGP key is a public key called the Certification Key. Keys.openpgp.org always leaves the Certification Key in the key because otherwise the identity of the key would be lost. There is a strong opinion out there that a public key is personal data as per the GDPR when used to identify a person¹⁾. The Certification Key directly identifies a person through the directly derived PGP key fingerprint. So deleting the User ID as performed by keys.openpgp.org can't actually work to protect against the effect of the GDPR.

That is assuming that the GDPR could cause problems for a PGP keyserver in the first place. I spent some time researching the issue for the other article and now personally doubt that could be true.

So keys.openpgp.net doesn't actually do anything to prevent GDPR problems…

An observation: It has been suggested that a distributed keyserver network might meet the GDPR deletion requirement by simply blacklisting a key. So the key would be deleted only on that particular server and would no longer be imported from any source. I don't think that just deleting data on a single node of a distributed network would be enough here. Otherwise we would have a serious GDPR loophole. Any entity that wanted to retain data would just set up a distributed network for that purpose. Still, if it turned out that this was enough to end further discussion of the GDPR vs keyservers this might still be an important feature for a keyserver to support.

Third Party Signatures

In 2019 someone added a lot of third party signatures to some PGP keys and uploaded them to a keyserver network. These keys would then take a long time to import. That was a problem as there did not seem to be any easy way to fix the situation. So keys.openpgp.org is preventing the problem by deleting all the third party signatures. That of course has the obvious downside of losing all of a user's third party signatures. One of the reasons PGP keyservers exist is to propagate such signatures.

So keys.openpgp.org destroys your third party signatures…

OpenPGP Standards

Accommodating keys.openpgp.org behaviour is arguably making the OpenPGP standards schism worse. The RFC-9580 proposal allows a key with no User ID to make the strategy used by keys.openpgp.org work. The people behind the LibrePGP proposal strongly disagreed and disagree with this and as a result LibrePGP requires a User ID for a valid key.

Accommodating keys.openpgp.org behaviour seems to have led to an attempt to have the RFC-9580 proposal retroactively modify the RFC-4880 standard (what we use now). RFC-9580 claims that RFC-4880 keys (version 4) no longer require a User ID. Attempting to retcon a standard that has been around basically forever in this way is logically confusing and raises philosophical questions that should not have to be addressed. It is not an idea that those that are sitting out the PGP standards schism war by sticking with RFC-4880 would likely support. They would not like the idea that there is an attempt to change the existing standard to conform to the very thing they are avoiding.

Keys.openpgp.org behaviour summed up:

Standard (key version)	Result
RFC-4880 (ver 4)	Damage
LibrePGP (ver 5)	Damage
RFC-9580 (ver 6)	No Damage

So keys.openpgp.org breaks your standards…

There are two formats for packets in OpenPGP, old and new. The test key I uploaded to keys.openpgp.org was in RFC-4880 (what we use now, version 4) format and had all old format keys. Keys.openpgp.org reformatted all the packets to new packets. Here is what RFC-4880 says about old vs new packets:

PGP 2.6.x only uses old format packets. Thus, software that interoperates with those versions of PGP must only use old format packets. If interoperability is not an issue, either format may be used.

The two major standards proposals (RFC-9580, LibrePGP) specify that new format packets should be used unless there is a reason not to do so. But neither can be reasonably read to suggest that existing keys should be reformatted and they of course don't apply to RFC-4880 keys. This is an example of how keys.openpgp.org is opinionated and imposes those opinions on the keys of the users who have entrusted their keys to it.

There is currently a problem with hostile patches where implementations are patched to comply with a standard proposal against the wishes of the maintainers of the project. The big issue here is that this is being done without a proper fork. A patch to allow the keys.openpgp.org behaviour is being deployed in this way.

So keys.openpgp.org breaks your implementations…

Security

Traditional PGP key servers form a single network where each server contains the same keys. The servers embody an append-only scheme so that the entities running the servers have little control over the keys. That control rests with the owners of the keys. A particular server operator can maliciously modify a key, but that modification will not propagate to the other servers on the network.

Keys.openpgp.org on the other hand is a single server. It has no append-only characteristic. It is a simple repository of PGP keys. If the operators wanted to maliciously modify keys they would have no difficulty in doing so and there would be no way to check that such a modification had occurred.

So keys.openpgp.org is less secure than traditional PGP key servers.

The Ways This Seems Pointless

We start with the apparent pointlessness of doing anything in response to the GDPR. That is followed by the apparent pointlessness of only deleting the User ID and leaving the rest of the personal data in the key. But there is other potential pointlessness available here…

Instead of just deleting the User ID, why not just delete the entire key when someone requests erasure? That would work just as well against the imagined GDPR threat and avoids all the other trouble. We want to create a PGP key server that works off email verification? Sure, just inform the user of the security tradeoff vs a traditional keyserver and everything's fine. When the user uploads the key just don't release the key until the email verification is complete and valid. On revocation just leave the key alone up until the point that erasure is requested. It is not like this was anything anyone ever cared about before the GDPR. We are almost entirely accommodating trolls here. There is no point in causing a lot of trouble just to appease the trolls.

I suspect that this might not be entirely about the GDPR. It might also be about creating a new class of PGP key where there is no distraction from the key fingerprint as indication of identity. Perhaps we are making a type of anonymous PGP key here. But you don't have to actually delete the User ID to do that. You can just put something in the User ID that does not identify an actual person. Since keys.openpgp.org runs off of email identity verification it would be trivial to allow a user to put whatever they wanted in the User ID, whenever they wanted.

Summary

Keys.openpgp.org:

breaks your cryptographic preferences.
breaks your revocations.
doesn't actually do anything to prevent GDPR problems.
destroys your third party signatures.
breaks your standards.
breaks your implementations.
is less secure than traditional PGP key servers.

PGP FAN index
Encrypted Messaging index
Home

¹⁾

“Thus, where the public key serves precisely to identify a natural person, the conclusion that it qualifies personal data appears unavoidable” from: Blockchain and the General Data Protection Regulation

When the GDPR Seems to Prevent an Entire Technology

b.walzer@undisclosed.example.com (b.walzer) — Tue, 10 Mar 2026 20:31:06 +0000

When the GDPR Seems to Prevent an Entire Technology

Only a Sith deals in absolutes.

^{Obi-Wan Kenobi, Star Wars: Episode III – Revenge of the Sith}

The GDPR (General Data Protection Regulation)¹⁾ is the current EU (European Union) privacy regulation. It has spawned an intellectual exercise where some provision of the GDPR is used to prove that the GDPR makes some system effectively illegal. Some examples:

Public blockchain based cryptocurrencies like Bitcoin: Europe’s New Data Guidelines Fuel Bitcoin Ban Fears
Artificial intelligence: Humans forget, machines remember: Artiﬁcial intelligence and the Right to Be Forgotten
Matrix messaging servers: Matrix notes
The World Wide Web: Does the GDPR break the Internet? The case for a public data exception

There are of course many other regulatory regimes out there and the general principles discussed in this article should apply. It just seems that these sorts of claims are often based on the GDPR.

The GDPR vs the SKS Network

I will use the relatively obscure synchronizing key server (SKS) network, not just because it fits with the PGP theme of this series of articles but because it works as a really good practical example.

The SKS (Synchronizing Key Server) network is a way to publicly publish PGP identities ²⁾. It has been around basically forever. It consists of a bunch of servers that communicate with the intent to have each server contain the same PGP identities in the same state. Uploading an identity results in that identity appearing on all the other servers.

It was suggested that the SKS network was somehow illegal around 2018 when the GDPR first went into force³⁾. The idea is that the append-only nature of the SKS network is fundamentally incompatible with the GDPR right to erasure (GDPR Article 17).

Why is the SKS network append-only?

Keeping a database synchronized across a network is normally a difficult and complicated problem even if you can trust the server operators. For the end to end encrypted PGP case the database must be secure against attacks from the server operators and others. The SKS design cleverly makes an assumption that simplifies the problem tremendously. The database is treated as an append-only data structure. So data goes into the network and stays there forever. This somewhat surprisingly works inside the identities since PGP identities are modular. The SKS network retains all the past portions of the identities during updates. So if you attempt to replace some aspect of the identity, after you upload it to the SKS network you will end up with both aspects in the identity on the network. This (also somewhat surprisingly) works out in practice when these identities are used. Implementations expect to see older components in PGP identities.

The append-only nature of the SKS network prevents an attacker from modifying the identities on the network by removing portions or replacing those portions with older portions. New encryption methods or signature keys stay new. A revoked key or complete identity stays revoked. Even if an attacker completely takes over a user's PGP environment they still can't prevent a user with access to a copy of the revocation certificate from revoking the identity and having it stay revoked forever. The important point here is that the distributed append-only nature of the network provides significant security advantages. The user gets a high level of control and security. The intent is that the people operating the servers get as little control over the user data as is possible. The most a server operator can do is modify their local copy. They can't maliciously downgrade the PGP identities on the rest of the network.

The GDPR Right to Erasure

(GDPR art 17 (1)) The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay where one of the following grounds applies:

… Followed by six grounds. Some of the grounds seem like they might apply to the SKS network. …

The security of the SKS network comes from the fact that it is append-only. In other words, that a right to erasure is not possible. This feels like the irresistible force meeting the immovable object. Since we can't just change the GDPR it is obvious that the SKS network will have to change. But we can't do that without making it ineffective. So obviously the SKS network must cease to exist. It vanishes in a puff of logic.

If you have a legal background you could be irritated right now. If you understand and respect the GDPR you might even be offended. Destroying a pre-existing system that has not been causing trouble, particularly one intended to enhance the privacy of individual citizens, is not what the GDPR is intended to do. So my argument pretty much assumes that the designers of the GDPR are, well, idiots.

In my defence, I work in technology. My world is full of absolutes. There is more electrical current going into a node than is coming out? A violation of Kirchhoff's current law. Then that can't be. Something has to change. I end up with more or less energy than I started with? A violation of the first law of thermodynamics. That can't be. Something has to change. Computer programming is all about dealing with absolutes. Hundreds … thousands of them.

I do understand the difference between the laws of the universe and the laws of humanity. But my instincts tend to betray me. My life in technology has created a sort of aggressive humility. I tend to be adamant that rules must be followed.

I will throw out a helpful principle here:

The law is designed to be reasonable.

We shouldn't initially assume the law is broken and things can't work. To have the SKS network continue to exist we have to be able to claim that the operator of an SKS server has the right to refuse to remove a PGP identity on the request of the owner of that identity. So let's assume that is true to start. Our job will be to find out why that is the case.

Personal Data

The GDPR is about protecting the rights of people over their data. So we have to consider what data in a PGP identity actually belongs to a user in a GDPR sense. Such data is called “personal data” (GDPR art 4(1)). If there is no data relevant to the GDPR here then we can skip the rest of the discussion.

What is, and is not, personal data under the GDPR depends on context. Here are two numbers:

57592 57592

The number on the left is my employee identification number. It identifies me in multiple employment related contexts. It counts as personal data under the GDPR. The number on the right is from an anonymized database. It identifies a particular person, but there is no way to relate it to an actual physical person. It does not count as personal data under the GDPR. So you may distribute, store or further process the rightmost number without my knowledge or consent. You can only distribute, store or further process the leftmost number with consideration of my rights under the GDPR.

But the numbers are the same! That is why this is such a good example; the actual value is not important, only the context⁴⁾.

It seems fairly clear that a public key used for identification can count as personal data under the GDPR. The question came up with respect to the public key used to identity users of blockchains⁵⁾. Does it count for the public key(s) in PGP identities?

A PGP identity normally will represent the identity of a person. The Certifying Public Key portion is the primary indicator of that identity. A shortened version of the Certifying Public Key is generated (key fingerprint or ID) specifically to make it easy to associate that public key with an actual person. There is also an Encryption Public Key which is unique to the user and is also linked to the Certifying public Key.

It is possible to use a PGP identity in an anonymous way where the embedded public keys would not count as personal information. But that is very much not normal usage and requires special care.

The key ID derived from the Certifying Public Key shows up in PGP signatures. A separate key ID derived from the Encryption Public key normally shows up as a plaintext portion of PGP encrypted material. So a PGP identity links signatures made by a user to material encrypted by that user.

From the proceeding I get that the public keys in PGP identities could very much be considered personal data.

There is also a User ID portion that provides a convenient handle for dealing with the PGP identity and is also linked to the Certifying public Key. It is an arbitrary string and might not be unique or even actually serve to identify a particular person. However, the convention is that it contains the name of a person and a PGP capable email address. So the User ID has to be treated as personal data.

The personal data here is:

the certifying public key (and derived key fingerprint/ID)
an encryption public key
a name
an email address

… and the fact that the values are probably linked. So a PGP identity seems to be chock full of personal data as defined by the GDPR.

The GDPR Right to Object

Ground (b) of the Right to Erasure (GDPR art 17(b)) is withdrawal of consent. You consented to some specific use of your data, but now you don't. Uploading a PGP identity to the SKS network seems like some sort of implied consent. But implied consent is not really a thing under EU privacy law. Website operators attempted to use the concept of implied consent to justify their use of tracking cookies. The regulators were not amused by that argument and now we have all those explicit consent tracking cookie banners to enjoy. The SKS network is specifically designed to prevent the control of the personal information by the organization (SKS network) and leave it under the control of the individual. So uploading a PGP identity to the network is a unilateral action. A unilateral action does not involve the concept of consent.

The question of consent doesn't matter in the end. The user can just base their request for erasure off the Right to Object (GDPR art 17(c) ⇒ GDPR art 21). The Right to Object is relevant when the user's data is being stored/processed for some legitimate reason. Such as, say, maintaining a secure public directory of PGP identities for a set of users as in the SKS network case. The user would be objecting to the existence of their PGP identity on the SKS network.

The Right to Object is not and can not be absolute. Your wish to delete your bad grades or your upcoming jail sentence should not be respected. These sorts of exceptions are known as “legitimate interests” (GDPR art 6(1)(f)).

Legitimate Interests

Legitimate interests are a very important consideration when considering questions related to the GDPR (GDPR art 6(1)(f))⁶⁾. There is a list provided of possible legitimate interest arguments (GDPR art 6(4)) but the use of the term “inter alia” means that this list is not exclusive. Any requirement for processing/storing personal data could be potentially considered valid. Logically it would seem that legitimate interests entirely nerf the GDPR … but that's the logic of absolutes. Instead this just means that the rights/needs of the entities involved need to be balanced in some reasonable way. Here that balance would involve the Right to Object of the user requesting erasure vs the Legitimate Interests of the other users of the SKS network.

The EU Right to be Forgotten

Typically the GDPR is about keeping private data private as much as possible, all the time. It is much easier to prevent the inappropriate use of data if the distribution of that data is strictly controlled. The SKS network case is somewhat special in that it involves data that someone deliberately made public but then attempted to make private at some time afterwards. That case most closely corresponds to the EU Right to be Forgotten. So it could be expected that a regulator would consider the SKS network in terms of that right.

Many places in the world have some sort of right to be forgotten. Canada for example has the Criminal Records Act which provides for the suppression of criminal records in some situations. The right to be forgotten in Europe predates the GDPR ⁷⁾ and the GDPR is designed to allow regulators to enforce such a right⁸⁾.

So let's balance the Right to Object against Legitimate Interests in the light of the right to be forgotten…

In Support of the Right to Object

Erasure could prevent verification of signatures made by the user.
Erasure could prevent the encryption of messages sent to the user.
Erasure could prevent email spam from the email address in the user ID.
Erasure could remove knowledge that a user with a particular name had ever used PGP.
Forever is a very long time to retain data.

In Support of Legitimate Interests

The possible consequences (GDPR art 6(4)(d)) are trivial. The right to be forgotten normally only concerns things like serious criminal convictions that could negatively affect a person's reputation. The sort of thing that could destroy a person's life⁹⁾
A PGP identity is not “special data” (GDPR art 6(4)(c) ⇒ GDPR art 9).
An important context here is that the “controller” and the “data subjects” are effectively the same group (GDPR art 6(4)(b)).
The PGP identity is being retained by the SKS network for the purpose of information security (GDPR recital 49), in particular, authenticity and integrity of the public stored data. That security is important to the users of the SKS network. Recitals (the “Whereas” section) are not part of the legally effective part of the GDPR, but again, Legitimate Interests are not limited to a particular set.
A search must be performed to extract a PGP identity from the SKS network. It will not show up if, say, the user's name is entered into an internet search engine. So the availability of the personal data is limited¹⁰⁾.

A regulator would likely be influenced by existing cultural expectations when assigning weights to the various relevant factors. The example of the unlisted telephone number represents this quite well. Back when paper telephone directories were a thing, you could get an “unlisted” phone number. That meant that your number was changed to something else and that new number was not included in any new directories. That was inconvenient for the person with the unlisted number because they would then have to individually inform all their correspondents of the new number. Some of those correspondents would have memorized the old number. That was as opposed to collecting all the old phone directories and burning them. That was obviously impractical and would cause a tremendous amount of trouble for a great many people. In the same way, PGP identities are normally kept at the end points and are not available for destruction. A regulator would start with the impression that the fairest course of action would be for the user to simply create a new PGP identity and abandon the old one.

It seems unlikely that a regulator would be very motivated to take an action that might cause harm to the SKS network. They certainly would not be forced into a course of action by the construction of the GDPR. The GDPR is designed to be reasonable. It is not based on absolutes.

What is the worst that could happen?

Between 2018 and 2023 only 1.3% of GDPR cases resulted in a fine¹¹⁾. The fines against individuals and small not for profit organizations tend to be on the order of a few hundred Euros¹²⁾. So, say, the operator of a SKS server can put some money in their sock drawer and not be concerned past that.

This feels unsatisfying, we really want to know if things are actually legal or not. But this is an important consideration when considering the risk associated with a regulatory regime.

What actually did happen?

Another important consideration is the history of enforcement against a particular sort of activity. Previous regulator activity is a good predictor of future activity. The GDPR was adopted in 2016 and became effective in 2018. There doesn't seen have been any GDPR action against the SKS network since then. Perhaps just as important, there doesn't seem to have been any action against other append only systems.

Making user data public is the primary purpose of the SKS network. Bitcoin on the other hand depends on an append only scheme and makes the transactions public as a result. The public release of financial transactions is of no particular benefit to the users and is often considered undesirable. So if a GDPR regulator came for the SKS network, they would have to go through Bitcoin and other similar systems on the way. Note that I am not suggesting that blockchain based currencies are special. There is likely some canary technology that works for Bitcoin.

This also feels unsatisfying. It is sometimes suggested that what is happening here is that the regulators are acting as “judge, jury and executioner” or are “picking winners and losers” by choosing what entities to investigate and prosecute. A regulator has a limited amount of time and resources¹³⁾. So a choice must be made. A regulator is given a mandate by a government. That mandate usually comes with a significant amount of flexibility. As part of that, the regulator is expected to concentrate on issues that are causing actual social harm. Prioritizing is an important part of a regulator's job.

The Attack Against the SKS network

In 2019 some users of the SKS network experienced a harassment campaign ¹⁴⁾. Someone downloaded some PGP keys from well known people, added thousands or tens of thousands of third party signatures, and then re-uploaded them to the network. This caused subsequent imports of those keys to take a long time. Since the SKS network is append-only there was no easy way to immediately resolve the problem. The harasser was exploiting the basic nature of the network.

There was still a significant amount of apprehension about the GDPR at the time. A sort of synergy occurred causing a level of hopelessness significantly more than the sum of both issues. The result of this actually caused significant damage to the network. There is no evidence that the GDPR threat was the result of any sort of maliciousness but the result was still the same.

That is why this is important. A legal theory can act as a sort of attack on a project/system. The result can be a loss of interest in the project/system. It might seem easier to resolve the claimed legal problem in a technical way rather than having to engage fully with the legal aspects. That approach often does not work and can waste a lot of time and effort.

Projects/systems without access to legal resources are particularly vulnerable to this sort of attack … most notably, open source based projects.

SKS server operators actually received (receive?) requests for erasure that they obviously could not fulfill¹⁵⁾. This might be a good place to mention that the GDPR has an explicit anti-trolling provision (GDPR art 12(5)) that is specifically intended to be used against such an attack.

Further Comments

The GDPR is very much about informing people about what is going to happen to their data (GDPR art 13(2)). Clients (web or application) with the capability to upload data to a keyserver often fail to inform the user that they are doing something that might be irrevocable. Warning a user that they are about to do something they can't undo is just good usability and is something that could be improved for the SKS network. When doing the research for this article, I was struck by how much the GDPR could double as a usability standard.

Forever is a long time. It probably wouldn't degrade security to define a point where an append-only network would forget about really old data that has not been updated by its owner for a very long time (say 20 years). Such a convention could be helpful for tidying up the network¹⁶⁾.

Conclusion

If I were to tell you that murder was legal in Canada you would be skeptical, even if you were not familiar with the laws of my country. But the statement is perfectly true, murder is legal in some situations involving self defence. The law is not absolute, even for the case of the most absolute law of all, the prohibition against murder. So if someone suggests that a particular technology is effectively illegal under some law you should be skeptical. You should apply a reasonableness test and if that test fails you should ask that someone to show how the law is so badly broken as to produce the unreasonable outcome. In the absence of a reasonable argument based on all of the law, not just some small portion of it, you will most likely be best off by just ignoring the suggestion and finding something more productive to worry about.

PGP FAN index
Encrypted Messaging index
Home

¹⁾

Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation)

²⁾

By “PGP identity” I mean the things that start with BEGIN PGP PUBLIC KEY BLOCK when ASCII armour is turned on. Otherwise I would have to talk about public keys inside public keys and I am not good enough at this to do that without causing lots of confusion.

³⁾

Keyservers and GDPR

⁴⁾

For another example of this sort of thing, see: What Colour are your bits?

⁵⁾

See section 3.3 of: Blockchain and the General Data Protection Regulation

⁶⁾

Guidelines 1/2024 on processing of personal data based on Article 6(1)(f) GDPR

⁷⁾

Right to be forgotten ECtHR and CJEU Case-Law

⁸⁾

The subtitle of GDPR article 17, the right to erasure is 'right to be forgotten'.