[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] is staying...again

From: Alin Anton
Subject: Re: [Sks-devel] is staying...again
Date: Fri, 23 Nov 2018 16:16:00 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3


On 11/22/2018 01:42 AM, Todd Fleisher wrote:
On Nov 21, 2018, at 12:59 PM, Yegor Timoshenko <address@hidden> wrote:

Do you happen to have a long-term patch also, or just the
hardcoded poison key?

I don't, and most importantly, I don't think a long-term patch is
even possible without completely overhauling SKS.

This may be true, but regardless I think we can all agree that a complete overhaul is not something that will just happen overnight. Furthermore, the SKS network of key servers is currently the best (and maybe only) game in town for mass public distribution of GPG keys so I think I speak for many people when I say let’s try to avoid introducing any more issues that could (and in my opinion should) be handled in isolated and controlled test environments vs. the actual network.

I agree with Todd here.

The first and more prominent one is, lack
of validation, closed as WONTFIX. That is also a critical UI flaw
that makes it easy to trick users who use HTTP interface.

I agree this issue (authenticity of data found on the key servers) is one many would like to see solved, but also agree it’s not what the SKS key server pool was designed for. Maybe SKS can be adapted to solve this problem or maybe it will require a new technology. Personally, I’ve solved for this issue on the client side by automating keyring management to some extent by checking for specific authority signatures (per domain) on keys found on the SKS network and then only import those that I deem “authentic". I know Micah (who reported that issue) has done something similar with GPGSync:

It is very easy to test for vulnerabilities if you actually
install sks on your own machine first, and try to also fix it
before publishing/exploiting it. Many have tutorials on this
subject and all you need is a copy of a key dump.

Not really. This particular key poison vulnerability can only be
seen if you have a testing network of at least three keyservers.

Those two sentences appear to be in opposition of each other. It would have just required more effort on the part of the tester to setup at least 3 key servers to test with.

I think setting up 3 SKS key servers on computers @ home / virtual appliances for the purpose of testing the vulnerability is not much. Unless, the main goal of the poison key was not to test a virtual network, but to damage the real one. It is similar to hammering a window on the street just because there will be no unpleasant consequences and you feel that it is right to do so.  The constructive comments are appreciated, though, and also your support for free software.

Anyway, Yegor, think of somebody uploading a PLEASE_READ_THIS.TXT file on your website by injecting some code into a web application saying "This website has a vulnerabilty.. CVE... Disclaimer.." . It is much better than defacing it and replacing the main page with random data or who knows what.

I didn't know the extent of damage my attacks will have: I was
just poking SKS for basic attack vectors that, at that time, I
was sure would have no effect at the network at large. I haven't
looked at SKS source code while testing any of the attacks

That first sentence really irks me. I personally would appreciate future testers taking heed of a proper testing approach vs. unleashing code/data containing unknown and/or unpredictable results onto the public SKS network that many people rely on every day.

If one does not trust the web of trust, by all means, one doesn't have to. One way of distributing your PGP key is via DNS:

"An OpenPGP DANE DNS record allows other users to download and validate your public OpenPGP key from your domain’s DNS server. In conjunction with DNSSEC this allows the users to know with a increased level of confidence that the key retrieved is the same public key that you published without modification."


Maybe services like DynamicDNS / noip will support this at some point (

I didn't even know these attacks had any pronounced long-term
effect on the network before ~3 weeks ago when I took a look at
sks-devel@ mailing list and found a huge discussion on the topic.
(I was never approached about this until recently.)

Not to beat a dead horse, but therein lies the problem. If you didn’t know what the impact would be, I feel you should not have injected test data into the SKS network without first doing due diligence in an isolated test environment.

Well.. Todd.. if you read it will make it all clear.

Historically speaking, it would seem as if benevolently attacking
the network was the most effective way to have it evolve. Say,
consider Evil 32, which was an effort that included bruteforcing
a 32-bit fingerprint lookalike to every key in trusted set
( and uploading it to keyservers. By then, the
danger of 32-bit key fingerprints was known for a long time, but
no one did anything about it.

I think that was different, Yegor:

"Someone downloaded our copy of the strong set and uploaded all of the keys to the SKS keyserver network. :( While we took on this project to help prompt GPG to build a more secure ecosystem, this mass clone made the keyservers harder for everyone to use. Of course anyone could use our tools to regenerate their own strong set clone and do this again, but we'd rather our keys not be used that way." (

If you actually know that it takes 3 SKS setups in order to test the vulnerability, it really shows that you are aware what the outcome could be when injecting the key into the public network supported by volunteers. That is not called "testing", it is explained as a deliberate attack on:  (same link as above)

nothing less.

And while that could cause problems for folks using the trusted set of GPG keys and 32-bit fingerprints … I don’t think it caused instability in the SKS network by way of increasing usage of server & network resources - neither of which are “free" for everyone - nor did it compromise nodes on the network when they crashed as a result of the bogus keys being uploaded.

There are other ways of bringing an sks server down, and BDB
might not be the best idea for a server, still the network is
important for both free software and individuals using it.

There are likely other low-effort ways of bringing an SKS server
down :-(

You are right that SKS network is still important to a lot of
people, however I believe that this trust has been misplaced.
Hopefully these attack vectors (and potential mitigations) being
public will bring awareness to the issue and motivate someone to
create a more robust alternative to SKS, and users to prefer less
exploitable ways to share keys (or choose a different encryption
scheme entirely, say one that has forward secrecy, or pursue more
contained tools for signatures such as OpenBSD signify(1) or

Encryption is not yet ready for the masses. I may be wrong, but I do not know if there is any way of setting up a private Signal ( server for conferencing with family members. I know the client is freely available, but what about the server side? Signal is mentioned in the article.

Yegor, will you try something similar on the fediverse?

I think Facebook has more data on you than any of the SKS servers combined, not to mention Google. It is more efficient to actually poison their network first, to show that their business model is flawed/unethical by design. It would make more sense, but it would still be unethical and perhaps illegal to do so.

I believe the importance of the SKS network to people is mutually exclusive of whether or not said people “trust” it. Like I mentioned earlier, it is of tremendous importance & value to myself and many people I communicate with … but we know the limitations and take additional measures to authenticate the data it provides. Sort of a trust, but verify model if you will. I trust it to be available world-wide for people to query and find GPG keys for the vast majority of people who are capable of receiving GPG email. I think verify the data I download from the network on the client side to make sure it’s authentic. Is it perfect? No. Do I still use it regularly despite it’s faults because it serves an important & useful purpose? Yes. Hopefully we will be able to address some of the issues being discussed, but let’s know trash what we have now because it’s not perfect.

The SKS network is even more important after the recent privacy
incidents that everybody knows about, and I wonder how safe is
PGP done in _javascript_, or sks key generation on Raspberry PI:)
. There were issues for ssh key pairs.

I don't think that SKS in its current state is safe to use.

Then by all means, don’t use it. Just don’t simultaneously ruin it for the rest of us who are still using it.

In closing, this isn’t meant to call out or pick on you specifically. I wanted to provide some color/context on why your responses might rub people the wrong way. Especially some of the people responsible for maintaining the SKS codebase and operating the nodes that make up the network. Your reply is acutely focussed on the shortcomings of the SKS network to the point of drawing conclusions that nobody should “trust” it (which to me reads like nobody should “use” it) and that it should be replaced with something better that addresses everyone’s concerns. But in the absence of such a replacement, many people will continue to rely on it and would appreciate if we could continue to do so until such time as something else is available.


P.S. Happy Thanksgiving to those of you who celebrate it!

In closure, please don't read this response as unfriendly or as criticizing, Yegor; your constructive comments are appreciated, however, the attack on the network is not, and later on you will probably agree it was unethical and it would have been a better idea to write a thorough paper on the subject after thoroughly testing it @ home.

I had to move from a VPS on a dedicated machine, which was meant for Mastodon (glad you are using the software), and it was partly because of the poison key. Thanks for pinpointing the blacklisting patch, I'll have to use it.

Best wishes,

-- Alin-Adrian Anton
Politehnica University of Timisoara 
Department of Computer and Information Technology
2nd Vasile Parvan Ave., 300223 Timisoara, Timis, Romania

reply via email to

[Prev in Thread] Current Thread [Next in Thread]