Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
SKS Keyserver Network Under Attack

SKS Keyserver Network Under Attack

This work is released under a Creative Commons Attribution-NoDerivatives 4.0 International License.

Terminological Note

"OpenPGP" refers to the OpenPGP protocol, in much the same way that HTML refers to the protocol that specifies how to write a web page. "GnuPG", "SequoiaPGP", "OpenPGP.js", and others are implementations of the OpenPGP protocol in the same way that Mozilla Firefox, Google Chromium, and Microsoft Edge refer to software packages that process HTML data.

Who am I?

Robert J. Hansen <rjh@sixdemonbag.org>. I maintain the GnuPG FAQ and unofficially hold the position of crisis communicator. This is not an official statement of the GnuPG project, but does come from someone with commit access to the GnuPG git repo.

Executive Summary

In the last week of June 2019 unknown actors deployed a certificate spamming attack against two high-profile contributors in the OpenPGP community (Robert J. Hansen and Daniel Kahn Gillmor, better known in the community as "rjh" and "dkg"). This attack exploited a defect in the OpenPGP protocol itself in order to "poison" rjh and dkg's OpenPGP certificates. Anyone who attempts to import a poisoned certificate into a vulnerable OpenPGP installation will very likely break their installation in hard-to-debug ways. Poisoned certificates are already on the SKS keyserver network. There is no reason to believe the attacker will stop at just poisoning two certificates. Further, given the ease of the attack and the highly publicized success of the attack, it is prudent to believe other certificates will soon be poisoned.

This attack cannot be mitigated by the SKS keyserver network in any reasonable time period. It is unlikely to be mitigated by the OpenPGP Working Group in any reasonable time period. Future releases of OpenPGP software will likely have some sort of mitigation, but there is no time frame. The best mitigation that can be applied at present is simple: stop retrieving data from the SKS keyserver network.

How Keyservers Work

When Phil Zimmermann first developed PGP ("Pretty Good Privacy") in the early 1990s there was a clear chicken and egg problem. Public key cryptography could revolutionize communications but required individuals possess each other's public keys. Over time terminology has shifted: now public key cryptography is mostly called "asymmetric cryptography" and public keys are more often called "public certificates", but the chicken-and-egg problem remains. To communicate privately, each party must have a small piece of public data with which to bootstrap a private communication channel.

Special software was written to facilitate the discovery and distribution of public certificates. Called "keyserver software", it can be thought of as analogous to a telephone directory. Users can search the keyserver by a variety of different criteria to discover public certificates which claim to belong to the desired user. The keyserver network does not attest to the accuracy of the information, however: that's left for each user to ascertain according to their own criteria.

Once a user has verified a certificate really and truly belongs to the person in question, they can affix an affidavit to the certificate attesting that they have reason to believe the certificate really belongs to the user in question.

For instance: John Hawley (john@example.org) and I (rjh@example.org) are good friends in real life. We have sat down face-to-face and confirmed certificates. I know with complete certainty a specific public certificate belongs to him; he knows with complete certainty a different one belongs to me. John also knows H. Peter Anvin (hpa@example.org) and has done the same with him. If I need to communicate privately with Peter, I can look him up in the keyserver. Whichever certificate bears an attestation by John, I can trust really belongs to Peter.

Keyserver Design Goals

In the early 1990s we were concerned repressive regimes would attempt to force keyserver operators to replace certificates with different ones of the government's choosing. (I speak from firsthand experience. I've been involved in the PGP community since 1992. I was there for these discussions.) We made a quick decision that keyservers would never, ever, ever, delete information. Keyservers could add information to existing certificates but could never, ever, ever, delete either a certificate or information about a certificate.

To meet this goal, we started running an international network of keyservers. Keyservers around the world would regularly communicate with each other to compare directories. If a government forced a keyserver operator to delete or modify a certificate, that would be discovered in the comparison step. The maimed keyserver would update itself with the content in the good keyserver's directory. This was a simple and effective solution to the problem of government censorship.

In the early 1990s this design seemed sound. It is not sound in 2019. We've known it has problems for well over a decade.

Why Hasn't It Been Fixed?

There are powerful technical and social factors inhibiting further keyserver development.

  • The software is Byzantine. The standard keyserver software is called SKS, for "Synchronizing Key Server". A bright fellow named Yaron Minsky devised a brilliant algorithm that could do reconciliations very quickly. It became the keystone of his Ph.D thesis, and he wrote SKS originally as a proof of concept of his idea. It's written in an unusual programming language called OCaml, and in a fairly idiosyncratic dialect of it at that. This is of course no problem for a proof of concept meant to support a Ph.D thesis, but for software that's deployed in the field it makes maintenance quite difficult. Not only do we need to be bright enough to understand an algorithm that's literally someone's Ph.D thesis, but we need expertise in obscure programming languages and strange programming customs.

  • The software is unmaintained. Due to the above, there is literally no one in the keyserver community who feels qualified to do a serious overhaul on the codebase.

  • Changing a design goal is not the same as fixing a bug. The design goal of the keyserver network is "baked into" essentially every part of the infrastructure. This isn't a case where there's a bug that's inhibiting the keyserver network from functioning correctly. Bugs are generally speaking fairly easy to fix once you know where the problem is. Changing design goals often requires an overhaul of such magnitude it may be better to just start over with a fresh sheet of paper.

  • There is no centralized authority in the keyserver network. The lack of centralized authority was a feature, not a bug. If there is no keyserver that controls the others, there is no single point of failure for a government to go after. On the other hand it also means that even after the software is overhauled and/or rewritten, each keyserver operator has to commit to making the upgrade and stomping out the difficulties that inevitably arise when new software is fielded. The confederated nature of the keyserver network makes changing the design goals even harder than it would normally be—and rest assured, it would normally be very hard!

The Vulnerabilities

The keyserver network is susceptible to a variety of attacks as a consequence of its write-only design. The keyserver network can be thought of as an extremely large, extremely reliable, extremely censorship-resistant distributed filesystem which anyone can write to.

Imagine if Dropbox allowed any Tom, Dick, or Harry to not only put information in your public Dropbox folder, but made it impossible for you to delete it. How would everyone from spammers to child pornographers abuse this?

Many of the same attacks are possible on the keyserver network. We have known about these vulnerabilities for well over a decade. Fixing the keyserver network is, however, problematic for the reasons listed above.

In order to limit the scope of this document a detailed breakdown of only one such vulnerability will be presented (see below).

The Certificate Spamming Attack

Consider public certificates. In order to make them easier to use, they have a list of attestations: statements from other people, represented by their own public certificates, that this certificate really belongs to the individual in question. In my example from before, John Hawley attested to H. Peter Anvin's certificate. When I looked for H. Peter Anvin's certificate I checked all the certificates which claimed to belong to him and selected the one John attested as being really his.

These attestations — what we call certificate signatures — can be made by anyone for any purpose. And once made, they never go away. Ever. Even when a certificate signature gets revoked the original remains on the certificate: all that happens is a second signature is affixed saying "don't trust the previous one I made".

The OpenPGP specification puts no limitation on how many signatures can be attached to a certificate. The keyserver network handles certificates with up to about 150,000 signatures.

GnuPG, on the other hand … doesn't. Any time GnuPG has to deal with such a spammed certificate, GnuPG grinds to a halt. It doesn't stop, per se, but it gets wedged for so long it is for all intents and purposes completely unusable.

My public certificate as found on the keyserver network now has just short of 150,000 signatures on it.

Further, pay attention to that phrase any time GnuPG has to deal with such a spammed certificate. If John were to ask GnuPG to verify my signature on H. Peter Anvin's certificate, GnuPG would attempt to comply and in the course of business would have to deal with my now-spammed certificate.

The Consequences

We've known for a decade this attack is possible. It's now here and it's devastating. There are a few major takeaways and all of them are bad.

  • If you fetch a poisoned certificate from the keyserver network, you will break your GnuPG installation.
  • Poisoned certificates cannot be deleted from the keyserver network.
  • The number of deliberately poisoned certificates, currently at only a few, will only rise over time.
  • We do not know whether the attackers are intent on poisoning other certificates.
  • We do not even know the scope of the damage.

That last one requires some explanation. Any certificate may be poisoned at any time, and is unlikely to be discovered until it breaks an OpenPGP installation.

The number one use of OpenPGP today is to verify downloaded packages for Linux-based operating systems, usually using a software tool called GnuPG. If someone were to poison a vendor's public certificate and upload it to the keyserver network, the next time a system administrator refreshed their keyring from the keyserver network the vendor's now-poisoned certificate would be downloaded. At that point upgrades become impossible because the authenticity of downloaded packages cannot be verified. Even downloading the vendor's certificate and re-importing it would be of no use, because GnuPG would choke trying to import the new certificate. It is not hard to imagine how motivated adversaries could employ this against a Linux-based computer network.

Mitigations

At present I (speaking only for myself) do not believe the global keyserver network is salvageable. High-risk users should stop using the keyserver network immediately.

Users who are confident editing their GnuPG configuration files should follow the following process:

  1. Open gpg.conf in a text editor. Ensure there is no line starting with keyserver. If there is, remove it.
  2. Open dirmngr.conf in a text editor. Add the line keyserver hkps://keys.openpgp.org to the end of it.

keys.openpgp.org is a new experimental keyserver which is not part of the keyserver network and has some features which make it resistant to this sort of attack. It is not a drop-in replacement: it has some limitations (for instance, its search functionality is sharply constrained). However, once you make this change you will be able to run gpg --refresh-keys with confidence.

Repairs

If you know which certificate is likely poisoned, try deleting it: this normally goes pretty quickly. If your OpenPGP installation becomes usable again, congratulations. Acquire a new unpoisoned copy of the certificate and import that.

If you don't know which certificate is poisoned, your best bet is to get a list of all your certificate IDs, delete your keyrings completely, and rebuild from scratch using known-good copies of the public certificates.

A Personal Postscript

dkg wrote a blog post about this. He sums up my feelings pretty well, so I'm going to quote him liberally with only a trivial correction.

I've spent a significant amount of time over the years trying to push the ecosystem into a more responsible posture with respect to OpenPGP certificates, and have clearly not been as successful at it or as fast as I wanted to be. Complex ecosystems can take time to move.

To have my own certificate directly spammed in this way felt surprisingly personal, as though someone was trying to attack or punish me, specifically. I can't know whether that's actually the case, of course, nor do I really want to. And the fact that Robert J. Hansen's certificate was also spammed makes me feel a little less like a singular or unique target, but I also don't feel particularly proud of feeling relieved that someone else is also being "punished" in addition to me.

But this report wouldn't be complete if I didn't mention that I've felt disheartened and demotivated by this situation. I'm a stubborn person, and I'm trying to make the best of the situation by being constructive about at least documenting the places that are most severely broken by this. But I've also found myself tempted to walk away from this ecosystem entirely because of this incident. I don't want to be too dramatic about this, but whoever did this basically experimented on me (and Rob) directly, and it's a pretty shitty thing to do.

If you're reading this, and you set this off, and you selected me specifically because of my role in the OpenPGP ecosystem, or because I wrote the abuse-resistant-keystore draft, or because I'm part of the Autocrypt project, then you should know that I care about making this stuff work for people. If you'd reached out to me to describe what you were planning to do, we could have done all of the above bug reporting and triage using demonstration certificates, and worked on it together. I would have happily helped. I still might! But because of the way this was done, I'm not feeling particularly happy right now. I hope that someone is, somewhere.

To which I'd like to add: I have never in my adult life wished violence on any human being. I have witnessed too much of it and its barbaric effects, stood by the graves of too many people cut down too young. I do not hate you and I do not wish any harm to befall you.

But if you get hit by a bus while crossing the street, I'll tell the driver everyone deserves a mulligan once in a while.

You fool. You absolute, unmitigated, unadulterated, complete and utter, fool.

Peace to everyone — including you, you son of a bitch.

— Rob

@idvorkin

This comment has been minimized.

Copy link

commented Jun 29, 2019

For those interested in the source: https://bitbucket.org/skskeyserver/sks-keyserver/src

@troyengel

This comment has been minimized.

Copy link

commented Jun 29, 2019

My dirmgr was failing while attempting to complete the TLS handshake as it could not validate the Let's Encrypt based certificate. Generally it looked like this:

Jun 29 10:40:25 grimm dirmngr[1382]: TLS connection authentication failed: General error
Jun 29 10:40:25 grimm dirmngr[1382]: error connecting to 'https://keys.openpgp.org:443': General error
Jun 29 10:40:26 grimm dirmngr[1382]: TLS verification of peer failed: status=0x0042
Jun 29 10:40:26 grimm dirmngr[1382]: TLS verification of peer failed: The certificate is NOT trusted. The certificate issuer is unknown.
Jun 29 10:40:26 grimm dirmngr[1382]: DBG: expected hostname: keys.openpgp.org
Jun 29 10:40:26 grimm dirmngr[1382]: DBG: BEGIN Certificate 'server[0]':
Jun 29 10:40:26 grimm dirmngr[1382]: DBG:      serial: 03D804FE5B5614E157F04E714A7BEBC64E91
Jun 29 10:40:26 grimm dirmngr[1382]: DBG:   notBefore: 2019-06-07 13:24:06
Jun 29 10:40:26 grimm dirmngr[1382]: DBG:    notAfter: 2019-09-05 13:24:06
Jun 29 10:40:26 grimm dirmngr[1382]: DBG:      issuer: CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US
Jun 29 10:40:26 grimm dirmngr[1382]: DBG:     subject: CN=keys.openpgp.org
Jun 29 10:40:26 grimm dirmngr[1382]: DBG:         aka: (8:dns-name16:keys.openpgp.org)
Jun 29 10:40:26 grimm dirmngr[1382]: DBG:   hash algo: 1.2.840.113549.1.1.11
Jun 29 10:40:26 grimm dirmngr[1382]: DBG:   SHA1 fingerprint: 163C12F44D3D2597904C2A86C091B9A7464E8BC4
Jun 29 10:40:26 grimm dirmngr[1382]: DBG: END Certificate
Jun 29 10:40:26 grimm dirmngr[1382]: DBG: BEGIN Certificate 'server[1]':
Jun 29 10:40:26 grimm dirmngr[1382]: DBG:      serial: 0A0141420000015385736A0B85ECA708
Jun 29 10:40:26 grimm dirmngr[1382]: DBG:   notBefore: 2016-03-17 16:40:46
Jun 29 10:40:26 grimm dirmngr[1382]: DBG:    notAfter: 2021-03-17 16:40:46
Jun 29 10:40:26 grimm dirmngr[1382]: DBG:      issuer: CN=DST Root CA X3,O=Digital Signature Trust Co.
Jun 29 10:40:26 grimm dirmngr[1382]: DBG:     subject: CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US
Jun 29 10:40:26 grimm dirmngr[1382]: DBG:   hash algo: 1.2.840.113549.1.1.11
Jun 29 10:40:26 grimm dirmngr[1382]: DBG:   SHA1 fingerprint: E6A3B45B062D509B3382282D196EFE97D5956CCB
Jun 29 10:40:26 grimm dirmngr[1382]: DBG: END Certificate
Jun 29 10:40:26 grimm dirmngr[1382]: TLS connection authentication failed: General error
Jun 29 10:40:26 grimm dirmngr[1382]: error connecting to 'https://keys.openpgp.org:443': General error

I went to the LE certificate page, saved the Root CA and both signed X3 (active) to a single PEM file in ~/.gnupg/ and added this to dirmgr.conf:

hkp-cacert <my home directory>/.gnupg/le.pem
keyserver hkps://keys.openpgp.org

Killed the running dirmgr process and retried the refresh and everything is happy. Hope this helps someone else having the same problem trying to test out the new keyserver.

@Mikotochan

This comment has been minimized.

Copy link

commented Jun 29, 2019

Not only do we need to be bright enough to understand an algorithm that's literally someone's Ph.D thesis, but we need expertise in obscure programming languages and strange programming customs.

A lot of popular algorithms were first introduced as part of someone's Ph.D thesis. There is nothing that makes them inherently more difficult to understand. In addition to that, calling OCaml obscure is silly.

Due to the above, there is literally no one in the keyserver community who feels qualified to do a serious overhaul on the codebase.

If they feel that way then they might also not be qualified to fiddle in cryptography. Just a thought.

How would everyone from spammers to child pornographers abuse this?

"How would everyone from spammers to homosexual pornographers abuse this?" is the version from 80 years ago. Maybe it is time for people to accept that nobody is harmed by people masturbating to certain sequences of bits. There is no need to be a bigot in an irrelevant topic.

Poisoned certificates cannot be deleted from the keyserver network.

The solution (for the server-side) is simple: each server individually handles spam. Although I would argue that the issue is not with the servers. I might have legitimate reasons for adding >150000 signatures to a certificate.

We've known for a decade this attack is possible

The fact that it was not fixed for the past decade might mean that the people behind the standard and its implementations are not qualified to develop cryptographic software.

But if you get hit by a bus while crossing the street, I'll tell the driver everyone deserves a mulligan once in a while.
You fool. You absolute, unmitigated, unadulterated, complete and utter, fool.

That person actually deserves a reward, if only for actually brining the attention of the community at large to this easily to exploit and known for a decade DoS attack. Even if you are not qualified enough to fix it then this might at least be the way to finally educate people of the dangers of OpenPGP and GPG.

@ghuntley
I am actually amused from the fact that he is using docx despite his involvement in a GNU project.

@cridenour

This comment has been minimized.

Copy link

commented Jun 29, 2019

How would everyone from spammers to child pornographers abuse this?

"How would everyone from spammers to homosexual pornographers abuse this?" is the version from 80 years ago. Maybe it is time for people to accept that nobody is harmed by people masturbating to certain sequences of bits. There is no need to be a bigot in an irrelevant topic.

@Mikotochan Are you seriously defending CP? You do understand how those sequences of bits are made, right?

@lfam

This comment has been minimized.

Copy link

commented Jun 29, 2019

These comments are mostly disgraceful and should be closed.

@Mikotochan

This comment has been minimized.

Copy link

commented Jun 29, 2019

@lfam
May I ask why you are defending censorship? I believe that there is a great opportunity for discussion concerning the issues of OpenPGP and how to get past them.

For example concerning the point of package signatures for distribution I believe that a minimalistic signature-verification tool (such as signify from OpenBSD) and fetching the signatures via package updates (just like debian does via the debian-keyring package) would be a great solution to the issue raised in the article above. In general I believe that avoiding big and monolithic software with bad security record (see https://dev.gnupg.org/T1579 as an example) such as GPG would be the best solution for anyone interested in a secure framework for future projects.

@cridenour
I would rather not pollute the thread with offtopic comments, especially with a topic that controversial. If you wish to engage in that discussion we could talk via some other medium.

Edit: There is a new article for anyone interested https://gist.github.com/rjhansen/f716c3ff4a7068b50f2d8896e54e4b7e

@qptain-Nemo

This comment has been minimized.

Copy link

commented Jun 29, 2019

Wouldn't it be possible for the PGP implementations to skip processing redundant signatures in an intelligent way?

@dmerillat

This comment has been minimized.

Copy link

commented Jun 29, 2019

I'm missing something: I understand the keyservers have to synchronize with each other, but you can't help clients by limiting results to the oldest 10,000 signatures or whatever GPG can handle until it asks with "I am a fixed version, give me the full set"?

@DigitalBrains1

This comment has been minimized.

Copy link

commented Jun 29, 2019

Due to the above, there is literally no one in the keyserver community who feels qualified to do a serious overhaul on the codebase.

If they feel that way then they might also not be qualified to fiddle in cryptography. Just a thought.

I think the context is that we're taking about modifying the reconciliation algorithm.

And yes, indeed. I do like to see my cryptographic algorithms modified only by people with a PhD in the field, and then peer-reviewed extensively before I use it. People modifying cryptographic algorithms outside those conditions are what I call "rolling your own crypto".

I get the feeling you're thinking about using an algorithm. Using an algorithm doesn't need intelligence, otherwise computers would be bad at it (since artificial intelligence is an algorithm, it's turtles all the way down).

@judge2020

This comment has been minimized.

Copy link

commented Jun 29, 2019

@lfam Unless we get @nat /other staff in here, authors can't close gist comments.

@dmerillat

This comment has been minimized.

Copy link

commented Jun 29, 2019

I'm missing something: I understand the keyservers have to synchronize with each other, but you can't help clients by limiting results to the oldest 10,000 signatures or whatever GPG can handle until it asks with "I am a fixed version, give me the full set"?

Replying to myself:
The most obvious problem is flooding a certificate with bogus signatures so that future signature revocations don't "take", but given that GPG is completely unusable with a flooded cert until something is fixed it's a reasonable risk for the mitigation.

Secondly, the "attackers" were being generous by targeting the keys of the maintainers instead of something that would cause a widespread outage. What would happen if they flooded a distribution signing key, or some key linux kernel developers, or really anything that is used constantly every single day for automated verification? There was a potential to cause real widespread harm here that they clearly knew how to do and chose not to.

@Mikotochan

This comment has been minimized.

Copy link

commented Jun 29, 2019

@DigitalBrains1

I get the feeling you're thinking about using an algorithm. Using an algorithm doesn't need intelligence, otherwise computers would be bad at it (since artificial intelligence is an algorithm, it's turtles all the way down).

Producing implementations of crypto algorithms should also only be done by experts. Just take a look at all side-channels that libgcrypt (the library that gpg uses) had, here is a relatively recent example: https://eprint.iacr.org/2017/627.pdf.

@diafygi

This comment has been minimized.

Copy link

commented Jun 29, 2019

Howdy all, I'm interested in writing an sks-compatible keyserver implementation that can handle poisoned keys gracefully. I understand the HKP protocol, but I can't seem to find any documentation on the gossip/reconciliation protocol. All I can find is the academic paper, which is very hard to understand.

Does anyone understand the gossip protocol on a technical level and would you be willing to mentor me as I learn it?

@IzzySoft

This comment has been minimized.

Copy link

commented Jun 29, 2019

@troyengel on Linux Mint 18.3 I wasn't able to get the DBG lines. Not even the TLS ones. Only gpg: keyserver refresh failed: General error. Thought it cannot hurt and followed your advice, worked like a charm. Thanks!

@sundhaug92

This comment has been minimized.

Copy link

commented Jun 30, 2019

Seems Kristian Fiskerstrand (0x0B7F8B60E3EDFAE3), who runs the SKS pool might also be affected

@BrainBlasted

This comment has been minimized.

Copy link

commented Jun 30, 2019

For those interested in the source: https://bitbucket.org/skskeyserver/sks-keyserver/src

Is this the source to the code running on keys.openpgp.org or the unmaintained code?

@dmbaturin

This comment has been minimized.

Copy link

commented Jun 30, 2019

@Mikotochan

A lot of popular algorithms were first introduced as part of someone's Ph.D thesis. There is nothing that makes them inherently more difficult to understand. In addition to that, calling OCaml obscure is silly.

From a quick look, there's no "idiosyncratic dialect" of it either, in the current codebase anyway. There's some camlp4 extension usage here and there, antiquated build system, and deprecated modules, but it doesn't look much worse than most other projects started more than a few years ago in the pre-OPAM, pre-PPX, pre safe string era. The only thing that caught my eye as peculiar is declaring things as mutually recursive with "let ... and ..." without an obvious reason, but that's still clear and not harmful.
In the commit history there are quite recent signs of modernization effort by a well-known OCaml community member too.

@ageis

This comment has been minimized.

Copy link

commented Jun 30, 2019

I'm pretty sure I've already fallen victim, due to my tendency to refresh keys periodically. Question: can this "attack" manifest in messages about an "invalid packet"? My suspicion is that people might be injecting signatures containing invalid GPG packets, which also causes keyring corruption.

For a specific example, take a look at the Tor Project signing key:

$ apt-key adv --recv-keys --keyserver keys.gnupg.net 886DDD89
gpg: requesting key 886DDD89 from hkp server keys.gnupg.net
gpg: packet(13) too large
gpg: read_block: read_error: invalid packet
gpg: Total number processed: 0
gpg: no valid OpenPGP data found.
@DigitalBrains1

This comment has been minimized.

Copy link

commented Jun 30, 2019

Producing implementations of crypto algorithms should also only be done by experts.

I fully agree. The latter bit was tongue-in-cheek, but as you point out, that unfortunately just made it wrong.

@optmzr

This comment has been minimized.

Copy link

commented Jun 30, 2019

@Mikotochan

How would everyone from spammers to child pornographers abuse this?

"How would everyone from spammers to homosexual pornographers abuse this?" is the version from 80 years ago. Maybe it is time for people to accept that nobody is harmed by people masturbating to certain sequences of bits. There is no need to be a bigot in an irrelevant topic.

This must be the most ignorant comment I've ever read on GitHub.

The thing is, someone is harmed, because you create a demand of new content. And this content is seldom created with consent (and there are many cases of sick abuse).

And then you go on and say:

I would rather not pollute the thread with offtopic comments, especially with a topic that controversial. If you wish to engage in that discussion we could talk via some other medium.

Well, weren't you the one who begun with defending this controversial topic? Don't mention it if you're not interested in defending your stance here.

@Mikotochan

This comment has been minimized.

Copy link

commented Jun 30, 2019

@optmzr

Well, weren't you the one who begun with defending this controversial topic?

Very well then, let me fix it: "I would rather not pollute the thread anymore with offtopic comments". If you are truly interested in a debate make a new gist or something and I will join you.

@yminsky

This comment has been minimized.

Copy link

commented Jun 30, 2019

I've been mostly uninvolved in SKS and the OpenPGP world more generally for 15 years or so, but I thought I would pipe in with a few quick thoughts.

Some points have been made about the difficulty of getting into this codebase. Some of the concerns are about the complexity of the math in the papers that describe the underlying synchronization techniques, and some have to do with the language and the way it was written.

I think the concerns about the complexity of the math are mostly misplaced. The math is all there to do one simple thing: quickly discover the set of keys that are different between two servers, so they can exchange the missing data. That's not the bit that would need to be fixed here.

The concerns about how the code is written are a bit off, I think. The code is definitely old, and uses some not-well-supported bits of technology (the build system, the now mostly-deprecated camlp4), but it's not written in style that would be foreign to most OCaml programmers. (It's not as well tested or documented as I would like, but that hardly distinguishes it from, say, PKS, the software it largely replaced.) OCaml itself is, obviously, not widely known, and the community would do better if it could attract some interest from the OCaml community in helping maintain it. One avenue might be to reach out to http://discuss.ocaml.org and see if you can attract some interest there. I think modernizing the codebase so it didn't depend on camlp4 and built cleanly with Dune, would be a good start.

But really, the most interesting questions here are really ones of policy. How should deletion work? SKS is based on a notion of monotonicity: you need to have a notion of what it means to make progress. Currently, that notion of progress is just merging all the data together. If you have two copies of the same keys with different signatures, just merge them. If there's a key you don't know about, add it.

One way you could move forward would be to allow the owner of a key to have the discretion of deleting signatures on that key, by dint of creating a signed instruction to remove particular signatures. A harder question is how you decide to delete keys that are themselves malicious. Does one create a central authority for that? Or does one allow individual keyservers to just delete keys autonomously, and share the deleted nature of that key with others?

From my perspective, if the OpenPGP community (which I no longer really count myself among) wants to make this infrastructure work, it needs to find people who are willing to invest real time in it; either by building a new keyserver codebase with a different approach to replication, or by working through the problems with the SKS model. And it's not clear to me that SKS's model is the right one. SKS errs on the side of making replication highly reliable; but that has downsides, and in particular requires some thought as to how to make deletion work. There are other designs that are less insistent on getting all the data everywhere, but that make deletion simpler.

@hackbunny

This comment has been minimized.

Copy link

commented Jun 30, 2019

@lfam Unless we get @nat /other staff in here, authors can't close gist comments.

How appropriate for an article on abuse of write-only storage

@dmbaturin

This comment has been minimized.

Copy link

commented Jun 30, 2019

@yminsky I'm now seriously considering a pull request to modernize the codebase to build with 4.08 no camlp4, no mutable strings defaults. Since yesterday I'm a self-proclaimed coordinator of Concerned CAMLers Against Camlp4 project that so far consists of one person and has a whole one pull request in its track record. ;)
But that's not the point.

If anyone in the PGP community is interested in an experience of a "moron in a hurry" who only occasionally used key servers by hand to lookup keys, I had no idea the system is byzantine. I never wondered if I can make my own key server because nothing on openpgp.org or any key server website ever says you actually can join the network. For this reason I always thought that replication is something the key servers are doing among themselves.
Even if I had an idea to follow the SKS repo link, a large project with just a repo and no website or docs other than a README screams "you won't be able to run it". I know it's a faulty heuristic, but I'm just as prone to fauty heuristics as any other human.

@pmetzger

This comment has been minimized.

Copy link

commented Jun 30, 2019

@dmbaturin Please do that. It would be hard to maintain if it doesn't build against at least 4.07 after all.

And all, I'm both an OCamler and a cryptoplumber. I might be able to spare a little time assisting with code cleanup if someone tells me what needs cleaning. (No guarantees I have real time to devote, but I can at least look.)

@XVilka

This comment has been minimized.

Copy link

commented Jun 30, 2019

@thorsummoner

This comment has been minimized.

Copy link

commented Jul 1, 2019

without knowing all the details, does it do anything to have a client electively only check the signatures of trusted keys (or keys of a specific/minimum trust level, or specified keys, whitelisting)?
The database is built to distribute full cooperates, so i expect that downloading 0.15megasignitures isn't really the problem and any kind of blacklist is contrary to the design anyway. The problem manifesting in that a client that would both fetch an unbound set of referrential keys and signitures as well as check the signatures puts undue load on systems as well as probably causing faults in software that wasn't tested at this signing scale, that's how i interpret the problem anyway, lmk.
a communal whitelist/blacklist approach seems like the first line of defense to me.

thanks for the great write up and your support

@subscribernamegoeshere

This comment has been minimized.

Copy link

commented Jul 1, 2019

general remark: pgp is not only meant for securing email communication. the pgp ID is not to be regarded as an email address of whatsoever nature. it mustn or does not need to be an email address. it is just to be regarded as a label. the public and private key combination and the possession thereof is resulting in actual ownership of a communication channel. not a mere email address or a string that calls itself an email address.

is nobody but me using pgp IDs in other places with little or no connection to email? i use PGP in fora and many other places where no smtp, no emails no of this stuff is being used.

think again people. this bug and the whole "validating email addresses" or trying to tie pgp to email foremostly is completely insane and laughable. :(

@Nihlus

This comment has been minimized.

Copy link

commented Jul 1, 2019

I'm no expert in any way, shape, or form, but I do see one way for us to start making a directory of affected keys by intentionally invoking the fault. Setting up a series of distributed virtualized machines (Docker, or something similar) that continually trawl the published keys from the keyserver system and attempt to utilize the keys could give us a way to mark poisoned keys - if it can be synchronized and utilized, it's green, and if the container breaks, it's red. Both results go into an independent database that can be utilized to verify that a key is "safe" before use. Perhaps something to prototype and utilize as a mitigation?

@pmetzger

This comment has been minimized.

Copy link

commented Jul 1, 2019

Setting up a series of distributed virtualized machines (Docker, or something similar) that continually trawl the published keys from the keyserver system and attempt to utilize the keys could give us a way to mark poisoned keys - if it can be synchronized and utilized, it's green, and if the container breaks, it's red.

Given that access to the underlying database is possible and that a relatively simple algorithm will tell you if a key is impacted, this seems like a very heavyweight solution to a relatively straightforward problem.

@Nihlus

This comment has been minimized.

Copy link

commented Jul 1, 2019

Setting up a series of distributed virtualized machines (Docker, or something similar) that continually trawl the published keys from the keyserver system and attempt to utilize the keys could give us a way to mark poisoned keys - if it can be synchronized and utilized, it's green, and if the container breaks, it's red.

Given that access to the underlying database is possible and that a relatively simple algorithm will tell you if a key is impacted, this seems like a very heavyweight solution to a relatively straightforward problem.

Agreed, now that I've had more than five seconds to think about it :P Having a directory of affected keys for mitigation purposes may still be a reasonable idea, though.

@ssaavedra

This comment has been minimized.

Copy link

commented Jul 1, 2019

Putting the blame in that the old SKS is written in OCaml while writing the new one in Rust seems somewhat counterintuitive for the long-term sustainability.

I'm sure there's people already more engaged on this, but if you need help with the OCaml SKS code, I could chime in a bit.

@sipa

This comment has been minimized.

Copy link

commented Jul 1, 2019

This is probably not useful information unless someone is already committed to writing new keyserver infrastructure, but better set reconciliation algorithms exist now than the one used by SKS (which is based on cpisync, I believe). Me and a few other contributors have been working on a high performance C-callable library that implements a more performant one (called pinsketch), https://github.com/sipa/minisketch. It seems like a good choice to base new keyserver design on.

Feel free to reach out if you have any questions.

@NullFlex

This comment has been minimized.

Copy link

commented Jul 1, 2019

Not only do we need to be bright enough to understand an algorithm that's literally someone's Ph.D thesis, but we need expertise in obscure programming languages and strange programming customs.

A lot of popular algorithms were first introduced as part of someone's Ph.D thesis. There is nothing that makes them inherently more difficult to understand. In addition to that, calling OCaml obscure is silly.

Due to the above, there is literally no one in the keyserver community who feels qualified to do a serious overhaul on the codebase.

If they feel that way then they might also not be qualified to fiddle in cryptography. Just a thought.

How would everyone from spammers to child pornographers abuse this?

"How would everyone from spammers to homosexual pornographers abuse this?" is the version from 80 years ago. Maybe it is time for people to accept that nobody is harmed by people masturbating to certain sequences of bits. There is no need to be a bigot in an irrelevant topic.

Poisoned certificates cannot be deleted from the keyserver network.

The solution (for the server-side) is simple: each server individually handles spam. Although I would argue that the issue is not with the servers. I might have legitimate reasons for adding >150000 signatures to a certificate.

We've known for a decade this attack is possible

The fact that it was not fixed for the past decade might mean that the people behind the standard and its implementations are not qualified to develop cryptographic software.

But if you get hit by a bus while crossing the street, I'll tell the driver everyone deserves a mulligan once in a while.
You fool. You absolute, unmitigated, unadulterated, complete and utter, fool.

That person actually deserves a reward, if only for actually brining the attention of the community at large to this easily to exploit and known for a decade DoS attack. Even if you are not qualified enough to fix it then this might at least be the way to finally educate people of the dangers of OpenPGP and GPG.

@ghuntley
I am actually amused from the fact that he is using docx despite his involvement in a GNU project.

shut the fuck up stupid anime pedo

@remowxdx

This comment has been minimized.

Copy link

commented Jul 1, 2019

I have no idea of the algorithm, software, protocols, feasibility ... but doesn't it make sense if the keyservers only published to the clients the key attestation if the keys are reciprocally attestated?
If Alice signs Bob's key, the servers should wait till also Bob signs Alice's key, so they know Alice is not a spammer.
Also add a flag/command/whatever to get the old behaviour.

@Disasm

This comment has been minimized.

Copy link

commented Jul 1, 2019

You can detect infected keys with this script: https://gist.github.com/Disasm/dc44684b1f2aa76cd5fbd25ffeea7332
4E2C6E8793298290 (Tor Browser Developers) is infected.

@co-dan

This comment has been minimized.

Copy link

commented Jul 2, 2019

Why does GnuPG choke on the flooded keys? It doesn't seem like it's an unprocessable amount of data, at least at the moment.

@rozzin

This comment has been minimized.

Copy link

commented Jul 2, 2019

Howdy all, I'm interested in writing an sks-compatible keyserver implementation that can handle poisoned keys gracefully. I understand the HKP protocol, but I can't seem to find any documentation on the gossip/reconciliation protocol. All I can find is the academic paper, which is very hard to understand.

Does anyone understand the gossip protocol on a technical level and would you be willing to mentor me as I learn it?

@diafygi, you (and maybe @rjhansen?) might find this other keyserver implementation, Hockeypuck, of interest—looks like it's supposed to be protocol-compatible with SKS, but written in Go instead of OCaml: https://hockeypuck.github.io/

Hockeypuck implements the HKP draft protocol specification as well as
several extensions to the protocol supported by SKS.
[...]
Hockeypuck can synchronize public key material with SKS and other Hockeypuck servers.
Recon protocol support is provided with the Conflux package.
@pmetzger

This comment has been minimized.

Copy link

commented Jul 3, 2019

Let me repeat that you have several OCaml types who have volunteered in the thread to help with the code.

@rozzin

This comment has been minimized.

Copy link

commented Jul 3, 2019

Let me repeat that you have several OCaml types who have volunteered in the thread to help with the code.

@pmetzger, if that's a response to my referencing Hockeypuck..., that wasn't really the point I was trying to make. Just that people who have difficulty understanding an algorithm or protocol from one particular implementation, or as implemented in one particular language, often benefit from having other references to read and compare. I've been in that situation enough times, myself. :\

"unfamiliar algorithm in an unfamiliar language" can be hard, and having either of those pieces swapped out even temporarily can help convert the situation into something more like "familiar algorithm in not-so-unfamiliar language".

Thank you for summarizing the OCaml situation as well :)

Such an effort does actually need someone to lead it, though; @dmbaturin, if you're taking the lead on this, thank you!

@tlhonmey

This comment has been minimized.

Copy link

commented Jul 3, 2019

Reading through all the ideas, I have to say that allowing signed instructions for modifying keys is probably a good idea. It would be just as secure as a revocation certificate in terms of censorship resistance and with a little capacity for simple logic like Etherium's smart contracts it would allow mitigation of this attack and probably others as well without needing further modification of the server software.

Implementing this wouldn't necessarily have to be done in the server software itself either. The current system prevents censorship by resynchronizing data deleted from one (or a few) servers. However modifications could still be made by having all server operators make the modifications between synchronization runs. All that is needed is an automated way to verify a signed command to replace a certificate's data with a clean copy (Or just delete it even and the original user can reupload.) and a communications framework allowing the servers to coordinate running it simultaneously.

@dadosch

This comment has been minimized.

Copy link

commented Jul 3, 2019

As @Dissam wrote key 4E2C6E8793298290 by the Tor Project also got spammed. This means that gpg hangs, even when you try to list your own secret keys.

You can delete such a key using gpg --delete-key 4E2C6E8793298290

To sort keys by size use the command from here: https://dev.gnupg.org/T3972#127356

@rozzin

This comment has been minimized.

Copy link

commented Jul 3, 2019

Is there a discussion somewhere I can read about the idea of using RFC 6091 to restrict keyservers to only accept certificate-uploads from clients with access to the private part of the key being certified (e.g. "you can only attach signatures to your own key"), and why maybe that's not a good idea or not workable?

@hunterpayne

This comment has been minimized.

Copy link

commented Jul 4, 2019

Perhaps I have a solution. So the SKS software replicates in a write only pattern. What if a new feature were added to the protocol. A blacklist which can be sync'ed between servers just like the whitelist is now. Then when authorizing a cert, just authorize against both the white and black list and only approve if the white is authorized and black is not. Then put poisoned certs into the blacklist.

Putting a cert in a blacklist might require proof the cert was your or belonged to your organization somehow. I'm not a security researcher so I'm sorry if this suggestion is a bit naive but it seems like at least part of a successful plan to address this.

Good luck and thanks for the software PGP folks,
Hunter

@Mikaela

This comment has been minimized.

Copy link

commented Jul 4, 2019

Hi, I think the mitigations section is missing a third step; killall -HUP dirmngr so it reloads its config file and the keyserver change comes to force.

@yawpitch

This comment has been minimized.

Copy link

commented Jul 4, 2019

How would everyone from spammers to child pornographers abuse this?

"How would everyone from spammers to homosexual pornographers abuse this?" is the version from 80 years ago. Maybe it is time for people to accept that nobody is harmed by people masturbating to certain sequences of bits. There is no need to be a bigot in an irrelevant topic.

By confusing those who create those sequences of bits with those merely masturbating to them you abandon credibility. By pretending those masturbating to those sequences of bits aren't complicit in, and party to, the crimes of those creating them, you dig the hole even further. Further, by drawing a line of moral equivalence between sequences of bits involving consenting adults and sequences of bits involving a consenting adult and children who cannot consent you abandon humanity.

Absent either credibility or humanity your views on any further pollution of a thread you polluted will be ignored.

@webdawg

This comment has been minimized.

Copy link

commented Jul 4, 2019

make any address one time use, and sign all future updates/requests for that same address w/ previous certs...even if they are expired.

done.

@Ridderby

This comment has been minimized.

Copy link

commented Jul 4, 2019

@webdawg

make any address one time use, and sign all future updates/requests for that same address w/ previous certs...even if they are expired.

In times of ransomware it is reasonable that one might need to start all over without any access to earlier private keys. Same applies to disk crash or unintentionally formatted disks, or re-installation of Linux because of this very problem unless you are over average skilled to navigate the .-directories. I am, my wife is not (still KDE lover though).

@tessus

This comment has been minimized.

Copy link

commented Jul 4, 2019

We've known for a decade this attack is possible.

Hmm, I guess I stop right there. Well, maybe one little remark: Ok, so what the heck did you expect?

Also, it would have been useful to provide a list of poisened keys and/or a way to detect them.

@stevefan1999-personal

This comment has been minimized.

Copy link

commented Jul 5, 2019

No, it's all about your ignorance to turn a blind eye on potential attacks since you claimed you know them for decades. Now we users, with less expertised hand at this, had to pay for this turmoil.

@webdawg

This comment has been minimized.

Copy link

commented Jul 5, 2019

@webdawg

make any address one time use, and sign all future updates/requests for that same address w/ previous certs...even if they are expired.

In times of ransomware it is reasonable that one might need to start all over without any access to earlier private keys. Same applies to disk crash or unintentionally formatted disks, or re-installation of Linux because of this very problem unless you are over average skilled to navigate the .-directories. I am, my wife is not (still KDE lover though).

How about the possibility of just signing previous keys...at least at a bare minimal you could follow a cert chain...attacks could be smaller because the chain would be broken with any public disclosure of a private key, but how is that different now?

@Ridderby

This comment has been minimized.

Copy link

commented Jul 5, 2019

Open source is what it is. Things are only made because someone (that might be a cooperate) puts an effort to do it of reasons only known for them self.

I recon that @rjh are working on some parts of this mess but is not involved in the SKS servers where the problem lies and are most likely busy with his stuff. No one expect him to skip what he is doing and learn what OCaml to fix something someone else developed. Who of you wold step up and say "Hey, this is important. I leave my current spare time interests, learn some new programming language and get involved in some algos I don't understand to fix something old but crucial for the community"? Some would, most of us would not. No point of blaming him for that.

Besides, developing a fix is in this case not pure technical. A new strategy need to be developed, then implemented. There is a distributed network that need to agree on the strategy and allow the changes to be released on their node.

We are in this mess together. Open source is a community where we actually cannot put strains on each other. I am not obliged to develop security patches for my software and I am free to leave development behind when I feel so. We rely on the statistical fact that someone somewhere feels that this is a task for him/her and get busy on.

What we do need to address is how the community shall deal with vulnerabilities like this. Whom to address them to when there is no maintainer, how to find enthusiasts to look at them, how to develop strategies with some relevant pace. This thread is one way but it is a bit late.

I think the only expectation I would have on rjh in this case would bee to report to such a community security forum, given it's existence at the time this problem was on his mind a decade ago.

It would actually be an interesting project to fire up something like that. An open source security board where security problems in open source software can be reported and where the need for a a community effort fixing them can be identified. Doing the actual fix is for the community. Possibly also support addressing the strategies needed. If someone more is interested in this, please contact me and perhaps something can be done.

<Edit: fixed typos>

@DigitalBrains1

This comment has been minimized.

Copy link

commented Jul 5, 2019

Is there a discussion somewhere I can read about the idea of using RFC 6091 to restrict keyservers to only accept certificate-uploads from clients with access to the private part of the key being certified (e.g. "you can only attach signatures to your own key"), and why maybe that's not a good idea or not workable?

My guess would be that the sks-devel mailing list is the best place, but since the problems have been known for ages, it could be quite a search. I don't read the list myself.

Any solution to the problem will quickly fall short of the monotonicity requirement for progress in the SKS network. I have not looked into it, but I suspect the problem is as follows. When some keyserver has a signature that another keyserver is not willing to accept, you have a fundamental problem: the only way to progress toward completion of the sync is if the keyserver that has the unwanted signature would drop it. But that breaks the monotonicity requirement: his dataset would shrink rather than grow or stay equal. However, since the other keyserver is unwilling to accept the signature, you cannot reach a state where all keyservers have the same data, which is what defines completion of the sync. Now, I did not look into it, I just read the terms "monotonicity requirement" and "progress to completion" and extrapolated from that. So don't take my word for it.

Of course it's possible to design an algorithm that can work with this, but you can't just strip out requirements from an existing algorithm because those requirements were used in the proof that the algorithm is correct. You'll have to come up with an alternative proof (if it exists).

My personal view is that we probably need to sunset the current keyserver network. A lot of work has been spent the last years to design alternatives to the keyserver network (because it was known there were big problems). Some pieces of the puzzle are still missing, so it's unfortunate hands were forced at this stage. When I say "unfortunate" I mean "criminal" and "very much black hat".

Hi, I think the mitigations section is missing a third step; killall -HUP dirmngr so it reloads its config file and the keyserver change comes to force.

  1. The recommended form of the equivalent command is gpgconf --reload dirmngr
  2. Actually, some or all versions of dirmngr will not pick up a new configuration file but instead only reload existing config files, it seems. This has been reported upstream. So gpgconf --kill dirmngr is needed if you created dirmngr.conf because it did not exist yet.

Finally, let me point out that GnuPG 1 should not be used for anything else than accessing years-old legacy data and thus shouldn't interact with keyservers at all. Use a supported GnuPG 2.x version, either upstream supported or supported by your distribution. If you need to add to your public keyring of GnuPG 1, download the key with 2.x and export it to a file to import in 1.x.

By pretending those masturbating to those sequences of bits aren't complicit in, and party to, the crimes of those creating them, you dig the hole even further.

Furthermore, it is horrible for many victims to think about how the images of their abuse are still being spread and masturbated to, and it hinders their recovery from the gruesome trauma inflicted on them. So even in the unrealistic scenario that the spread of images of abuse would not itself create a demand for new content, we owe it to the victims to try to eradicate the availability of imagery of the horrible things that have happened to them.

@antman2

This comment has been minimized.

Copy link

commented Jul 6, 2019

I'm missing something: I understand the keyservers have to synchronize with each other, but you can't help clients by limiting results to the oldest 10,000 signatures or whatever GPG can handle until it asks with "I am a fixed version, give me the full set"?

@dmerillat: Maybe I'm missing something, too. This seems to me like a good start to the solution. What reason is there to an unlimited number of attestations on a certificate anyway? Isn't there some level of "good enough" for attestations? 10,000 seems like as good a number as any.

My modification to this, though, would be to still allow revocations to be attached from any of the authors of attestations, i.e.: allow a given certificate to have up to 10,000 attestations and then up to 10,000 revocations from the same set of attestations.

@jhwoodyatt

This comment has been minimized.

Copy link

commented Jul 8, 2019

@dmbaturin @pmetzger I can probably lend a hand too, provided somebody takes the lead.

@pmetzger

This comment has been minimized.

Copy link

commented Jul 8, 2019

@jhwoodyatt I don't get the impression anyone understands that an offer was made to help. I've kind of given up. I don't think the people running the system are organized enough to accept the help.

@dmbaturin

This comment has been minimized.

Copy link

commented Jul 8, 2019

@pmetzger @jhwoodyatt I've been busy fixing some other libs that are of more immediate importance for my own project, but my offer to help bringing SKS to 4.07 is still valid.

@jhwoodyatt

This comment has been minimized.

Copy link

commented Jul 8, 2019

My hunch is that lack of OCaml programming expertise is not the problem here. However, if I'm wrong about that, then my offer to help out stands. I haven't looked at in any depth, but my guess is that I can probably best help out by backing out the dependency on CamlP4.

@sac001

This comment has been minimized.

Copy link

commented Jul 11, 2019

It is nice that programmers like to help, but I would suggest that you study the GDPR first a bit to see if it is worth the effort.
For example, when you guys and girls like to fix issues I would suggest that you look also at the option for users to delete
their data ... (chapter 3, article 17)

https://gdpr-info.eu/

@pmetzger

This comment has been minimized.

Copy link

commented Jul 12, 2019

@sac001 Ah, so in addition to DoS's being done against the key servers, you're attempting to do a legal FUD DoS! Excellent work!

@hunterpayne

This comment has been minimized.

Copy link

commented Jul 12, 2019

@sca001, you Europeans are free to not use technology if you wish. It seems to be what your governments want anyway...

@sac001

This comment has been minimized.

Copy link

commented Jul 12, 2019

@hunterpayne, but what hinders, for example, U.S. citizens to trollwot EU citizens pub keys or upload illegal material with SKS "technology"? We Europeans have at least now super modern and GDPR compliant Hagrid key server technology. :-)

https://github.com/search?q=trollwot
https://github.com/search?q=keyserver-fs

Maybe we should discuss it here too ... :-D
https://www.quaxio.com/message_board_over_pgp_key_servers.html

@IzzySoft

This comment has been minimized.

Copy link

commented Jul 12, 2019

@pmetzger why take everything as accusation? I rather understood that as "feature request" (which I'd second).

@hunterpayne our politicians are as much industry-driven as yours. But in case of GDPR they accidentally did what "we, the people" wanted: help us protect our privacy. Something that's not in the best interest of some US organizations, maybe (and yeah, some of ours are a bit unhappy as well). So why not treat this as "feature request"? Would it hurt someone?

All: Is there someplace where one can follow the progress made on the issue – without details of who accuses whom of what, and why which language is to be used etc? Say, for the interested end-user not being able to contribute in development? I'd like to see the milestones reached – but rather without that much background noise (not accusing anyone of anything: to reach agreements one must discuss terms – it's just not what the "simple end user" needs to follow in detail)?

@sac001

This comment has been minimized.

Copy link

commented Jul 12, 2019

@sac001 Ah, so in addition to DoS's being done against the key servers, you're attempting to do a legal FUD DoS! Excellent work!

If your time allows you may read this article:

https://medium.com/@mdrahony/are-pgp-key-servers-breaking-the-law-under-the-gdpr-a81ddd709d3e

@yawpitch

This comment has been minimized.

Copy link

commented Jul 12, 2019

@sac001 Ah, so in addition to DoS's being done against the key servers, you're attempting to do a legal FUD DoS! Excellent work!

If your time allows you may read this article:

https://medium.com/@mdrahony/are-pgp-key-servers-breaking-the-law-under-the-gdpr-a81ddd709d3e

I Am Not A Lawyer, that said I, for one, did read that article. The author’s conclusion is not entirely compelling, and neither should it be, since the author is also Not A Lawyer. The author doesn’t help themselves by choosing to both repeatedly advertise an alternative for-profit service on the one hand while disclaiming that advertising with the other. Also their very late IANAL disclaimer, near the bottom, doesn’t help things. When a non-lawyer asks (much less concludes) if a law (the GDPR is not a law, it’s a regulation) is being broken (one cannot “break” a regulation) by a piece of software (software can neither — at least as yet — break laws nor breach regulations), that non-lawyer’s conclusions should be approached from a position of strong skepticism. Perhaps we should wait until there’s some more compelling arguments before piling feature requests on to what may simply end up being abandoned.

That said I’m not sure complete immutability of arbitrary, easily vandalized blobs of text is a necessary feature of a key server.

@pmetzger

This comment has been minimized.

Copy link

commented Jul 12, 2019

why take everything as accusation? I rather understood that as "feature request" (which I'd second).

Nothing is likely to be taken as a feature request, and you're not going to write the change yourself, so it probably isn't going to happen. And regardless, PGP is likely going to die, perhaps slowly, perhaps quickly. This is because the ratio of the number of people who like to talk a lot to the number of people capable of implementing changes to the code is getting very, very high.

Matt Green claims that PGP dying is a good thing and that it's long since past the point where PGP should vanish; whether he's right or wrong about the should, clearly this thread demonstrates that it is, indeed, quite likely to happen. If so, In Pax Requiescat. It was a good thing when it was created, advanced the state of the art, and I don't regret my role in its early history decades ago.

@cmars

This comment has been minimized.

Copy link

commented Jul 13, 2019

I have a few ideas, but none of them are really that easy:

Signatures can be themselves signed (signature type 0x50). Perhaps we should only accept signatures that have been accepted by the signee with such a cross-signature as valid, and ignore unauthenticated signatures. That would require some changes to gnupg, and users would have to opt in and create cross-signatures on existing signatures that matter.

Keyservers could also mutually authenticate signatures, by requiring email verification before accepting key material. On uploaded key material, the keyserver encrypts an email to the key signer and the signed key's email addresses, with nonce HTTPS links in the email to prove key ownership and acceptance of the new keys and signatures. Material isn't accepted until verified by both the signer and signee. Email addresses and/or public keys could be rate-limited to prevent abuse. Keyservers then certify the verified keys with their own key; gnupg could be configured to refuse to accept key material not vouched for by a keyserver, or at least warn about it. It could also come with a trusted curated directory of keyservers.

Or we could go fully decentralized and put the key signatures on a blockchain, and make packet publishing cost something. There's probably some clever hacker out there already building this with ipfs and an ETH smart contract.

@NgoHuy

This comment has been minimized.

Copy link

commented Jul 16, 2019

I used gpg.mozilla.org, it was not affected by this attack. I recommend you add this server to this article
---FIXED---
use keys.openpgp.org with identify-keys works fine. All key owners should verify before using this service.

@pmetzger

This comment has been minimized.

Copy link

commented Jul 16, 2019

I used gpg.mozilla.org, it was not affected by this attack.

And if the attackers wanted to, how long would it take them to attack any new keyserver? Zero time, essentially. So what's the point if telling people to use a server that hasn't been attacked yet? Is it to encourage new servers to be attacked?

@NgoHuy

This comment has been minimized.

Copy link

commented Jul 16, 2019

I used gpg.mozilla.org, it was not affected by this attack.

And if the attackers wanted to, how long would it take them to attack any new keyserver? Zero time, essentially. So what's the point if telling people to use a server that hasn't been attacked yet? Is it to encourage new servers to be attacked?

what's different with keys.openpgp.org? keys.openpgp.org is not compatible with gnugp's keys. You cannot search or fetch new keys with this server. gpg.mozilla.org is not pool of SKS too.

@sac001

This comment has been minimized.

Copy link

commented Jul 16, 2019

I used gpg.mozilla.org, it was not affected by this attack.

And if the attackers wanted to, how long would it take them to attack any new keyserver? Zero time, essentially. So what's the point if telling people to use a server that hasn't been attacked yet? Is it to encourage new servers to be attacked?

what's different with keys.openpgp.org? keys.openpgp.org is not compatible with gnugp's keys. You cannot search or fetch new keys with this server. gpg.mozilla.org is not pool of SKS too.

Why do you think it is not compatible? And you can search for keys there:

https://keys.openpgp.org/search?q=

or put the key server URL in your config file and then GnuPG uses this server for fetching.

@NgoHuy

This comment has been minimized.

Copy link

commented Jul 17, 2019

I used gpg.mozilla.org, it was not affected by this attack.

And if the attackers wanted to, how long would it take them to attack any new keyserver? Zero time, essentially. So what's the point if telling people to use a server that hasn't been attacked yet? Is it to encourage new servers to be attacked?

what's different with keys.openpgp.org? keys.openpgp.org is not compatible with gnugp's keys. You cannot search or fetch new keys with this server. gpg.mozilla.org is not pool of SKS too.

Why do you think it is not compatible? And you can search for keys there:

https://keys.openpgp.org/search?q=

or put the key server URL in your config file and then GnuPG uses this server for fetching.

with latest gnupg, user should show this message.
image

@NgoHuy

This comment has been minimized.

Copy link

commented Jul 17, 2019

Sorry, I forgot to verify my email, then the key on pgp will be treated as non-identify.
It's fine now.

@nukeop

This comment has been minimized.

Copy link

commented Jul 17, 2019

sorry, that was me. I started vim, then I pressed something, and it just kept making those beeping noises and started saying something about certificates, signatures, and gpg. i have no idea what happened, sorry

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.