
SKS Keyserver Network Under Attack - Spellman
https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
======
tptacek
I'd like to gingerly suggest that this is not the way a project that has
deliberately set as its adversaries hostile world governments should respond
to a trivial, predictable† vandalism attack.

Rather, if they're serious about what they're doing – Hansen, in a related
document, talks about the "good advice" he gave to dissidents in Venezuela
about using GnuPG – they should thank whoever did this. This attack apparently
only hit the accounts of two maintainers – that is, two people who are, or
should be, exquisitely capable of distilling signal from the attack, and
making sensible decisions to mitigate it going forward.

A serious attacker, on the scale of the adversaries this project has, again,
deliberately selected for itself, wouldn't waste the vulnerability this way.
They'd wait for the most opportune time and apply the attack broadly to
accomplish their own state-level goals.

This isn't the first time the GnuPG ecosystem has responded this way to
attacks. They similarly (and dishonestly) attacked the Efail researchers, and
in the same document I referred to above, Hansen attacked EFF and Micah Lee
for publishing exploit code; "Academic freedom should not be construed as
permission to publish attack tools against a critical service with known
vulnerabilities". This is what you'd expect from one of the vendors posting
about a tempfile race condition on the CORE clique list in 1992; it's
preposterously out of step with how the field handles vulnerability research
today.

If you're relying on GnuPG for anything serious, you should be alarmed at the
way they react to security setbacks.

† _Indeed, repeatedly predict-ed_

~~~
yegortimoshenko
Can confirm, I've reported a similar attack [1], along with a few other
vulnerabilities, and also published exploit tools. I ended up getting legal
threats from two people that I see frequently posting to sks-devel@ mailing
list.

Additionally, Robert (GnuPG maintainer who wrote this Gist) has attacked [2]
another person who wrote a proof-of-concept filesystem on top of SKS that was
intended to highlight how broken the design is.

I have not seen a single open source community that would treat full
disclosure with such contempt.

At this point SKS network continues to run exclusively on community goodwill.
This attack seems to be specifically targeted on GnuPG maintainers, if
attacker were to deliberately try to break SKS, they would target someone like
Linus Torvalds.

Alternatively, there are other published vulnerabilities with exploits that
allow to take the whole SKS network down within half an hour, which were
published more than a year ago. And yet, those have not been used, so far.

[1]: [https://bitbucket.org/skskeyserver/sks-
keyserver/issues/57](https://bitbucket.org/skskeyserver/sks-
keyserver/issues/57)

[2]:
[https://twitter.com/robertjhansen/status/1017863443356020738](https://twitter.com/robertjhansen/status/1017863443356020738)

~~~
mirimir
> I have not seen a single open source community that would treat full
> disclosure with such contempt.

So what are the acceptable limits of this "full disclosure"?

~~~
yegortimoshenko
I should have said "any disclosure": EFail was coordinated (6 months notice
[1]) and yet GnuPG officially downplayed the risk [2], launched #effail
counter-campaign and blamed researchers for bad disclosure [3].

With regards to any of the existing SKS exploits specifically: even if any of
them were to undergo coordinated disclosure, it wouldn't have helped: trollwot
has been available for 5 years, both keyserver-fs and sks-exploit -- for more
than a year. Embargoes don't last that long. All three tools still work.

What GnuPG Project effectively tries to do is to stop people from writing
about any security problems period, especially those that are hard to fix.

[1]:
[https://gist.github.com/tqbf/2ef6bce7d16e9d3e76d790fd99c9618...](https://gist.github.com/tqbf/2ef6bce7d16e9d3e76d790fd99c96187)

[2]:
[https://twitter.com/gnupg/status/995936684213723136](https://twitter.com/gnupg/status/995936684213723136)

[3]:
[https://twitter.com/gnupg/status/996856990818283521](https://twitter.com/gnupg/status/996856990818283521)

~~~
mirimir
OK, makes sense. And damn, 10 years is >>> a year.

So then, as a mere user, I gotta ask how so much of the Linux ecosystem -- and
indeed, so much of the open-source ecosystem -- came to depend on such a
fragile thing as the SKS keyserver network. That's kinda mind-blowing.

------
JoachimSchipper
It's always sad to see someone taking down a project that is run with the best
intentions. However, it may be time to move away from the entire PGP
ecosystem.

Consider the post's "We've known for a decade this attack is possible. It's
now here and it's devastating.".

Consider also the final section, "PGP is bad technology and it’s making a bad
community", of [https://blog.cryptographyengineering.com/2018/05/17/was-
the-...](https://blog.cryptographyengineering.com/2018/05/17/was-the-efail-
disclosure-horribly-screwed-up/) (by noted cryptographer Matthew Green.)

My sympathies to the victims of this attack.

[EDIT: reworked slightly at 7m to try to be as kind as possible]

~~~
clarkmoody
The idea of Internet actors (human or machine) owning cryptographic identities
in a distributed system is a good one. I don't think we should stray from this
approach.

From your Matthew Green link:

 _> If PGP went away, I estimate it would take the security community less
than a year to entirely replace (the key bits of) the standard with something
much better and modern. It would have modern crypto and authentication, and
maybe even extensions for future post-quantum future security. It would be
simple. Many bright new people would get involved to help write the inevitable
Rust, Go and Javascript clients and libraries._

Those word were written a little more than a year ago. What if right now is
the time to assume that PGP has gone away and start building the next thing?

What alternate projects are people excited about that are solving the problem
of distributed cryptographic identity and messaging?

~~~
soulofmischief
It's not the silver bullet we need, but I really like Keybase's approach. I
think any PGP replacement should take notes from their architecture.

~~~
rocqua
I love their approach, but it is still PGP based. Moreover, it is a bit too
centralized.

Thing is, a non-centralized system is really hard to monetize. There might be
space for some long-form (as opposed to whatsapp, etc) encrypted messaging.
But a solution for portable encrypted files (using either symmetric or
asymmetric crypto) is hard to monetize.

Note that, while portable encrypted files could be used for encrypted
messaging, the use cases and ergonomics are sufficiently different that a good
solution for one will not be a great fit for the other.

~~~
soulofmischief
There's nothing technically wrong (baring a yet-unrevealed exploit) with PGP
itself. This thread's topic was about a weakness in SKS. PGP just suffers from
_major_ UX problems, which Keybase has largely addressed.

To use Keybase, one doesn't even need to know what PGP is. It all "just
works". I have successfully introduced non-technical people to Keybase and
what's more, these people use it actively and appreciate what it can do for
them. Can't really say that about PGP.

> Thing is, a non-centralized system is really hard to monetize

Until our government supports such infrastructure, the only solution is trust
funds / non-profit organizations which released all of their R&D for free.

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

Looking at the code [0], it looks like fairly standard Ocaml. Any particular
reason it's difficult to maintain (other than the lack of popularity of FP in
general)?

(It looks like the original author of the SKS Keyserver is Yaron Minsky, the
guy who convinced Jane Street to use Ocaml.)

[0] [https://bitbucket.org/skskeyserver/sks-
keyserver/src/default...](https://bitbucket.org/skskeyserver/sks-
keyserver/src/default/)

~~~
diafygi
> Any particular reason it's difficult to maintain (other than the lack of
> popularity of FP in general)?

A much bigger issue than the language itself is the overall architecture of
the server. It uses Berkeley DB as the main database and only handles one
connection at a time. So, if your gossip process starts syncing a huge spam
key, you block all front-end web requests (see my issue #61[1]). Also, the
keyserver is completely synchronous, so you effectively have to cluster
multiple keyservers running on different ports and different databases and
load balance across them if you want to add any sort of scalability to your
setup.

Overall, the server code feels like an MVP or academic implementation.
Definitely not designed for high scale or the ability to handle abuse like
this. It would take a heavy re-write to make get the server code to where it
needs to be, which is why no one has stepped up yet.

BTW, I'd love to step up and write an sks-compatible keyserver in python
(using postgres as the database), so that it could scale using something like
uwsgi, but so far I haven't been able to find a mentor who can help me learn
the gossip protocol that's largely undocumented.

[1]: [https://bitbucket.org/skskeyserver/sks-
keyserver/issues/61/k...](https://bitbucket.org/skskeyserver/sks-
keyserver/issues/61/key-addition-failed-blocks-web-interface)

~~~
acqq
Here in the comment however a new keyserver is presented:

[https://keys.openpgp.org/about/news#2019-06-12-launch](https://keys.openpgp.org/about/news#2019-06-12-launch)

by dpc_pw and Valodim

~~~
diafygi
I'm a bit confused as to the point you're trying to make. Can you please
elaborate?

------
lifeisstillgood
My attempt to understand this - please correct liberally

Things I know today that I did not know yesterday

\- The GnuPG (GPG) ecosystem seems to suffer from pre-heart bleed-OpenSSL
levels of not enough investment and people

\- The GPG ecosystem has a trivial DOS attack that can be mounted against it,
with bad actors able to append thousands of keys to any users "account"
effectively making it impossible to read that account, thus making anything
signed by that account impossible to verify

\- This may or may not mean that major distributions binary packages will
simply stop being verifiable - it depends on who uses what key server in what
chain of trust. We probably won't find out till more bad actors poison more
wells

\- This has been "well known" for some time but the solution is not obvious

\- It seems that this is the reason keybase works like it does : if a user
simply attests that key X is theirs in a second channel you can trust that as
much as you trust the channel. it a key server is the only channel and for
reasons will not delete the 150,000 bad keys

\- There are many alternatives to GPG it seems - or at least to the sub-
functions under its "brand". Signal to send message or minisign to sign
documents - it do they have the same "OpenSSL" lack of support in them?

\- Don't the million dollar companies like DocuSign use GPG?

So that's me - trying to work out if this is the end of the world or a storm
in a teacup - thoughts welcome :-)

~~~
danShumway
This roughly aligns with my understanding as well. The additional takeaways
I'd add (that may or may not be accurate):

\- Many security researchers disagree with the core idea of SKS servers in
general (they're essentially just undeletable online storage that anyone can
write to). The distributed "Web of Trust" model itself is considered
untrustworthy.

\- The vulnerability is triggered by the usage of the SKS servers. This is
very bad for any piece of infrastructure that relies on them, but if you're
only using local keys that you imported and verified yourself, this particular
attack doesn't effect you.

\- The PGP format itself is cumbersome and has problems (people want shorter
keys, and they want a simpler format with less variability). So while this
particular vulnerability only effects SKS servers, there's still a strong
movement to get rid of PGP in its entirety.

\- The fact that the people behind the SKS servers are reacting negatively and
angrily may be reason to be worried about GPG in general, since we don't know
if the maintainers would respond the same way to other vulnerabilities that
aren't restricted to SKS servers.

Similarly, thoughts or corrections welcome.

~~~
lifeisstillgood
Agreed - It would be nice to understand the dependency chain for SKS servers

And Inwoukd also like to understand what people mean by "get rid of GPG/PGP?"
\- it cannot mean get rid of keypairs, so it is just replace with some "nicer"
code? what is the problem?

------
ComodoHacker
>Any time GnuPG has to deal with such a spammed certificate, GnuPG grinds to a
halt.

So the SKS software is only a part of the problem. Another part is GnuPG,
which is unable to deal with a public key with many signatures attached.

GnuPG is written in C (not OCaml) and seems to be well maintained. Looks like
fixing it can be an effective mitigation against this attack. Or do I miss
something?

~~~
CameronNemo
Not sure how you could fix an OpenPGP client for this case without changing
how the keyservers function.

~~~
viraptor
"You're trying to pull more than reasonably supported 1k signatures. Do you
want to skip this step?"

~~~
maddyboo
This will protect your machine from being DoS’d, but what if your key is
poisoned? Nobody will be able to use it.

------
dpc_pw
Is the new berifing SKS from Sequoia PGP (written in Rust!) affected as well?
[https://sequoia-pgp.org/blog/2019/06/14/20190614-hagrid/](https://sequoia-
pgp.org/blog/2019/06/14/20190614-hagrid/)

~~~
Valodim
It is not! That's why the author recommends using the running instance at
keys.openpgp.org, as a replacement for the sks pool.

Note that Hagrid is _not_ an "sks in rust". It is different in a lot of ways,
see
[https://keys.openpgp.org/about/news#2019-06-12-launch](https://keys.openpgp.org/about/news#2019-06-12-launch)

(disclaimer: I maintain keys.openpgp.org)

------
geofft
It's fascinating that the conversation in the GitHub comments went to both
personal attacks on the author of the post and defending child pornography in
the span of like five responses.

I feel like part of the problem is that anyone who's skilled enough to
implement solutions has better things to do with their time than participate
in a discussion of that quality.

~~~
Waterluvian
Hmm. Has a site ever experimented with separate comment sections? Put simply:
on vs. Off topic (or maybe "meta") . Our comments would be in the off topic
section, for example.

I regularly see people apologizing for being off topic. Clearly they have
something they think is worth saying, but are afraid to pollute the discourse.

~~~
geofft
I think this falls into one of those social problems with no technical
solution. The culture of PGP, as described in the post itself, is that anyone
can participate, anyone can upload signatures, anyone can run keyservers,
there's no way to remove uploaded keys or signatures ever, and there's no
central authority for what is on the keyserver network. Given that culture,
there's a social expectation that if you're not going to let the pedophile
with the anime avatar have the rest of his arguments taken at face value,
you're censoring people and might as well go use one of those corporate sell-
out encryption systems like Signal.

(To your actual question: meta.stackoverflow.com, Wikipedia talk pages,
meta.wikimedia.org, etc. Also various email/chat communities have defined off-
topic lists/rooms. When the participants do actually want to keep off-topic
discourse to the side, and the off-topic discussion isn't an attack on the
competence of someone reporting a problem or a desire to propagate child
pornography, then it's merely a technical problem of enabling them to do it.)

------
despera
The author sounds a bit over dramatic and with many logical jumps, ocaml might
not be in the news and what cool kids use this days, that doesn't make it a
bad language. The base code doesn't look impossible to restructure. The attack
vector is know for long time. Also it's not like we haven't seen before
important code being pretty much unmaintained written in far more popular
languages e.g openssl.

------
amenghra
SKS don’t implement any modern web security features (the whole thing does
pre-date the web!) — as a result, you can (ab)use SKS as a free backend store
for your JavaScript apps:
[https://www.quaxio.com/message_board_over_pgp_key_servers.ht...](https://www.quaxio.com/message_board_over_pgp_key_servers.html)

------
dngray
Isn't WKD supposed to help out with key distribution for email?

* [https://wiki.gnupg.org/WKD](https://wiki.gnupg.org/WKD)

* [https://tools.ietf.org/html/draft-koch-openpgp-webkey-servic...](https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-08)

I'm thinking that's a better way to publish keys these days anyway.

I have my own domain, so maybe OPENPGPKEY record in my domain as well

DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP

[https://tools.ietf.org/html/rfc7929](https://tools.ietf.org/html/rfc7929)

~~~
Valodim
It would be a better way, but the technology hinges on support by e-mail
providers. I wouldn't recommend holding your breath.

The other contender is Autocrypt, which performs key exchange inline in emails
in an automated fashion. It only depends on client support, and has gained at
least some traction (enigmail, k9, mailvelope, gpgOL, delta.chat, and some
others).

~~~
dngray
> _It would be a better way, but the technology hinges on support by e-mail
> providers. I wouldn 't recommend holding your breath._

Ah.

> _The objective of the project was to develop new mechanisms for the reliable
> and automatic public PGP key exchange between e-mail providers. The results
> have also contributed to the WKS /WKD standard that is part of the GnuPG
> project._

[https://mailbox.org/en/security](https://mailbox.org/en/security)

I was looking at going with mailbox.org or possibly protonmail (though they
don't have calendars at the moment and I use that), both apparently support
it. As does Thundebird+Enigmail, K9/OpenKeychain.

I have noticed the AutoCrypt method.

Part of the reason I changed my email is because I had in the past submitted a
few keys to the sks network which I lost the private keys to, they were also
submitted with an infinite expiry. I was a stupid kid.

So I am unlikely to submit my new keys to the sks network. Just store them in
my domain, WKD, and on my blog.

~~~
Whatitat90
> Part of the reason I changed my email is because I had in the past submitted
> a few keys to the sks network which I lost the private keys to, they were
> also submitted with an infinite expiry. I was a stupid kid.

That's why most recent versions of GnuPG automatically create keys with expiry
set to 2 years.

------
libeclipse
The new keys.openpgp.org service is a mitigation:

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

~~~
paulfurley
I know the folks behind this and I think they’ve approached it thoughtfully
and realistically.

It’s using a modern OpenPGP implementation and language (Sequoia, Rust) which
is a big win. Despite it being centralised, I’d encourage folks to have a
look.

On that issue, SKS has become so troublesome to run that the number of peers
has steadily decreased to the point where there are only 2 entities running
the HKPS (“secure”) pool, so in reality SKS is centralised too, as well as
unmaintained. Source: I run a key server and a key expiry reminder service.

~~~
jlgaddis
Out of curiosity, which is more obscure: OCaml or Rust?

~~~
kchamplewski
Probably OCaml. While it's been around much longer, it's never really reached
mass acceptance (though does get used here and there). Rust is newer but I'd
estimate it's already more used, and its adoption in industry is growing quite
quickly.

This is probably to do with the fact that OCaml doesn't necessarily solve any
problems that are apparent to businesses, whereas Rust solves the very
apparent "manual memory management makes massive vulns trivial" problem.

I'm not sure which language is actually more approachable for someone trying
to learn it from scratch though.

~~~
AnaniasAnanas
OCaml is very popular in academia though, especially in the field of
theoretical computer science and formal verification. Coq, Frama-C, Flow,
CompCert, etc are all written in OCaml. Heck, if you are running a graphical
GNU distribution chances are that you have installed FFTW, which is written in
OCaml. The "industry" is not the only thing that matters when considering the
adoption of a language.

~~~
ghuntley
Reason (the frontend framework/language by Facebook) is OCaml.

~~~
literallycancer
Have you used Reason for anything serious? How was it?

------
xvilka
A bit more[1] on consequences of this attack, gist from the same author.

[1]
[https://gist.github.com/rjhansen/f716c3ff4a7068b50f2d8896e54...](https://gist.github.com/rjhansen/f716c3ff4a7068b50f2d8896e54e4b7e)

~~~
Forbo
This seems a bit "shoot the messenger" to me. If anything I think those
efforts should be applauded as the signal flares they are: "this is broken and
it's only a matter of time until it has real world consequences".

~~~
alasdair_
Seriously. The original post states at least three times they knew about the
issue for over a decade. At what point does "full disclosure" become valid if
not after over a decade of warning?

~~~
roywiggins
The fact that the chosen keys in this attack were _not_ Mozilla or whoever and
instead maintainers suggests to me that this "attack" is someone who, having
seen this vulnerability left unresolved for a decade, decided to force the
issue before someone used it for really nefarious purposes.

It's a black hat solution and not a nice thing to do at all. It's probably the
wrong thing to do. But, is this really worse than waiting for someone to use
this in earnest? I'm not sure.

------
vermilingua
To be clear: is this suggesting that it is currently entirely unsafe to update
any operation-critical equipment? It seems that now that the PoC is out in the
wild, it will be a matter of days/hours before someone hits a major
contributor to the major Linux distros; and all package managers begin to
fail.

~~~
koolba
Yes this seems like it's going to range from very bad to outright terrible. In
particular if the issue propagates prior to patching something like gpg as the
package managers would be locked out from updates.

Every time there's an article about IoT security there's a discussion about
lack of (security) updates and an upcoming Armageddon. Interestingly it'll be
those devices that do _not_ update that are immune to this type of thing.

~~~
heavenlyblue
>> immune to this type of thing.

The _only_ type of thing that they are immune to. This is like saying “a car
with a broken engine is the safest car in the world - it never moves!”.

~~~
majewsky
I think the standard analogy for this sort of thing is "a broken clock shows
the right time twice a day".

------
paulddraper
> unusual programming language called OCaml

> obscure programming languages

Huh, I knew OCaml was less popular; I did not know it was "obscue". Doesn't
Facebook use OCaml?

~~~
literallycancer
There's at most hundreds of people writing OCaml for non-academic purposes at
least once a week.

------
philips
I believe this is a project trying to replace the old school key servers.

[https://github.com/google/keytransparency/](https://github.com/google/keytransparency/)

~~~
majewsky
Is there any piece of distributed internet infrastructure that Google is not
trying to replace?

~~~
mschuster91
Probably not, it does make sense for Google though that they do not want to be
stuck with mission critical stuff they don't have the final authority on and
which is ... obscure in both code and people.

------
diafygi
I have maintained keyserver in the pool for many years[1], and attacks like
this are, in theory, able to be easily mitigated. I mean, we're only talking
about appending spam to public keys. It's not like the attackers found some
flaw in OpenPGP that breaks public keys or valid signatures. In theory, all
these attacks to do is cause bloat on keyservers.

So why can't we deal with these types of attacks? IMO, the main reason is the
the server code.

The author mentions that the sks keyserver is "written in an unusual
programming language called OCaml", but IMO the language isn't the main issue.
Here's a rundown of what I think the main issues are:

* Non-scalable database - SKS keyserver uses Berkeley DB as the database for storing keys, and bdb can't handle more than one connection at time. So, when huge keys with lots of spam signatures are being written to the database, it blocks all other transactions, including serving web requests (see issue #61[2]). The server needs to be re-written to use a database that can handle multiple connections (e.g. Postgres) so spam writes won't affect the web responses for unrelated keys. Unfortunately, the server is currently single-threaded and synchronous so it would have to be heavily re-written to add this kind of async scalability.

* Undocumented gossip protocol - The gossip protocol used is a very efficiency syncing algorithm that lets servers fill in the gaps for their databases from other servers. Unfortunately, the only documentation I can find on the gossip protocol is an academic paper[3]. This is a huge barrier for someone wanting to write a sks-compatible keyserver. You basically have to read the OCaml code (which doesn't have comments) to figure out how it works. For years I have wanted to try to write an alternative sks-compatible keyserver that could handle attacks like these better, but as it stands now, I'd have to spend a huge amount of time learning OCaml and reverse engineering the code just to understand how to write a compatible gossip implementation. Every once in a while I ask the mailing list for a mentor in helping teach me the gossip protocol[4], but so far either no one knows it or wants to teach it to me.

* Few validation and revocation features - OpenPGP is very flexible for how you can build public keys and signatures. I think there's a lot of creative things you can do with signature packets to let keyservers and public key owners clean spam out of their signatures. For example, OpenPGP signatures let you specify a "Signature Target"[5] in a signature, which could be used to let public key owners denote other signatures on their public key they wish to revoke, which the keyserver could then stop serving up to public requests. However, since the current server code is largely unmaintained, we can't implement some of these cleanup options.

Overall, I really love the idea of having a public, open, decentralized
keyserver pool. Unfortunately, sks-keyserver wasn't written with much ability
to scale (which was totally appropriate at the time), so it's in desperate
need of being re-written. I'd love to do it, but simply haven't found the time
to reverse engineer the gossip protocol. If someone out there wants to mentor
me through it, I'd happily write an sks-compatible keyserver that could
operate in the pool and also deal with these types of attacks.

[1]: [https://sks.daylightpirates.org/](https://sks.daylightpirates.org/)
(currently down)

[2]: [https://bitbucket.org/skskeyserver/sks-
keyserver/issues/61/k...](https://bitbucket.org/skskeyserver/sks-
keyserver/issues/61/key-addition-failed-blocks-web-interface)

[3]: [http://ipsit.bu.edu/documents/ieee-
it3-web.pdf](http://ipsit.bu.edu/documents/ieee-it3-web.pdf)

[4]: [https://lists.nongnu.org/archive/html/sks-
devel/2016-08/msg0...](https://lists.nongnu.org/archive/html/sks-
devel/2016-08/msg00072.html)

[5]:
[https://tools.ietf.org/html/rfc4880#section-5.2.3.25](https://tools.ietf.org/html/rfc4880#section-5.2.3.25)

~~~
giomasce
I don't think that the base issue lies in the implementation: you can make it
as scalable, parallel and document as you wish, but if what you are doing is
basically receive data from whoever sends you something, store it, pass it to
other server and do not offer any form of accountability over who can store
such data or who can delete it, it will always be trivial to write a script
that just sends lots of data and bloats your service. The problem lies in the
architecture itself.

~~~
diafygi
Hmmmm, isn't that an inherent property of any for-public-use database? By your
definition, any public pki (keybase.io, keys.openpgp.org, etc.), social
network (Twitter, Facebook, Mastodon, etc.), and more are vulnerable to
someone just writing a script and bloating their database.

What mitigation strategies do other ecosystems use? Why can't they be tried in
the keyserver pool?

~~~
viraptor
They certainly are vulnerable. The solutions for social networks are in
client/behaviour analysis: Are you trying to create 10th account from the same
IP? Are you creating multiple accounts with the same browser fingerprint? Have
you got any personal details attached? (That's one reason they started pushing
phone verification) Is the action automated? (CAPTCHA) Is your friend graph a
clique of fresh accounts?

A lot of these can't be applied to SKS unfortunately.

~~~
thejohnstone
You should create multiple account with different browser fingerprint for each
account. I usually use Kameleo software to load different profiles with
manipulated browser fingerprint [https://support.kameleo.io/article/what-is-
browser-fingerpri...](https://support.kameleo.io/article/what-is-browser-
fingerprinting/)

------
mirimir
Wow, that is quite the KCF. This is the core problem:

> The [SKS] 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 [OCaml] codebase.

The solution is simple: don't use the SKS keyserver network.

> High-risk users should stop using the keyserver network immediately.

I used to use it, but mainly I just send people signed messages, and ask them
to send me their public keys. I point them to my Keybase page, in case they
prefer to encrypted key.

But that isn't generally practical. So about the mitigation.

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

> Open gpg.conf in a text editor. Ensure there is no line starting with
> keyserver. If there is, remove it.

This part makes sense.

> Open dirmngr.conf in a text editor. Add the line keyserver
> hkps://keys.openpgp.org to the end of it.

I'm not sure whether that's necessary. For Debian users, adding
keyring.debian.org makes sense. But otherwise, isn't it best to get keys from
first-party sources?

------
perlin
Now may be a good time to plug a project we worked on at my last gig. KeySpace
uses IPFS to store PGP keys in a decentralized file system. We used a smart
contract on the Ethereum blockchain to store an address-hash lookup. What this
achieves is fully decentralized peer-to-peter encrypted communication. We used
it to facilitate trustless OTC negotiation and trading.

[https://medium.com/fluidity/keyspace-end-to-end-
encryption-u...](https://medium.com/fluidity/keyspace-end-to-end-encryption-
using-ethereum-and-ipfs-87b04b18156b)

~~~
chakalakasp
>peer-to-peter

Ooh er, missus

------
Havoc
>unlikely to be discovered until it breaks an OpenPGP installation.

Why can’t you just brute force this? ie rest all of them vs a pgp install and
see which keys break it.

At least you can quantify and pinpoint the poisoned ones then

------
ggm
Can somebody explain to me a legitimate use for a single key cross signed by
e.g. 100,000 other keys? Is the goal group communications?

I get that arbitrary limits are bad. And that an attack on a system can be
converted to an attack on a key, I'm not seeking mitigation in this question.

I just want to understand in some six degrees of Kevin bacon manner, if there
is a real use for a single large sign set rather than eg a merkle tree of
decomposed subsign sets?

------
snackematician
The suggested mitigation (editing `gpg.conf` and `dirmngr.conf`) doesn't seem
to work for me. In particular I created `~/.gnupg/dirmngr.conf` with a line
for the `keys.openpg.org` keyserver (and don't have a `~/.gnupg/gpg.conf`),
but `gpg --refresh-keys` still uses `hkps://hkps.pool.sks-keyservers.net`
which the gnupg Info (section 3.2 Dirmngr options) says is the default.

~~~
Valodim
Did you `killall dirmngr`? :)

~~~
snackematician
Thanks that solved my issue :)

------
DyslexicAtheist
that affects the onionbalancers as well then :(
[https://dev.gnupg.org/T3392](https://dev.gnupg.org/T3392)

------
jeffrallen
This is why we can't have nice things.

------
rasengan
I think that decentralized services, like SKS, require a sort of fee mechanism
(proof of effort, currency, or otherwise) that can prevent bad actors from
inserting malicious material. I definitely think this is one of the cases that
blockchain technology makes a lot of sense, and the disincentive of a fee
would do very will to mitigate this.

~~~
JoachimSchipper
How would a proof-of-work system, let alone a blockchain, work?

Apparently, GnuPG breaks badly at 150 000 signatures. You want adding a
signature to be doable on a really old laptop and/or low-end Android phone; a
motivated attacker can just choose to expand 1000 000 times as much effort as
a not-too-interested user on antiquated hardware.

Of course you can make adding a signature more expensive the more signatures
are already there, but that lets a motivated attacker make it impossible to
vouch for certain users (keys.) Etc.

