======Keys.openpgp.org Breaks Your Keys====== //This article will be presented in the form of a rant...// [[https://keys.openpgp.org|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 sub rsa2048 2025-11-04 [E] [expires: 2025-11-18] I am not a big fan of [[pgpfan:expire|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 [[http://www.mew.org/~kazu/proj/pgpdump/en/|pgpdump]] to reveal the structure of the key which I have condensed to: - Public Certification Key - User ID ("Test Key ") - 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 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 (comp 2) Comp alg - BZip2(comp 3) Comp alg - ZIP (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 ") - 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: * [[pgpfan:gdpr|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(("Thus, where the public key serves precisely to identify a natural person, the conclusion that it qualifies personal data appears unavoidable" from: [[https://www.europarl.europa.eu/RegData/etudes/STUD/2019/634445/EPRS_STU(2019)634445_EN.pdf|Blockchain and the General Data Protection Regulation]])). 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 [[pgpfan:schism|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 [[pgpfan:hp|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 [[pgpfan:signedanon|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. [[pgpfan:index|PGP FAN index]]\\ [[em:index|Encrypted Messaging index]]\\ [[:|Home]]