- cypherpunks - lists.cpunks.org

SKS Keyserver Network Under Attack
by coderman 01 Jul '19

01 Jul '19

https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f SKS Keyserver Network Under Attack This work is released under a [Creative Commons Attribution-NoDerivatives 4.0 International License](http://creativecommons.org/licenses/by-nd/4.0/). 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](mailto:rjh@sixdemonbag.org?subject=SKS%20Keyserver%20network%20attack)>. 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(a)example.org) and I (rjh(a)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(a)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: - Open gpg.conf in a text editor. Ensure there is no line starting with keyserver. If there is, remove it. - 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](https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html) 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

4 5

Social media services support account spoofing
by Ryan Carboni 01 Jul '19

01 Jul '19

Social media services support account spoofing, this simplifies the creation of government sockpuppets. Government sockpuppets can also assume the history of other accounts (this is a simple series of mysql commands, any codebase can accomplish this by copying entries and assigning them to a new ID), This is a substantial concern to privacy rights. I am being harassed when I attempt to form new friends over the internet. The US government has effectively controlled my entire life, and I condemn it entirely. I see no use for the DOJ Inspector General if this conduct is so widespread that in my particular case it is considered to be permissible. I think all social media websites that failed to engage in proper oversight of this "investigation" should have computer issues. Sent with [ProtonMail](https://protonmail.com) Secure Email.

7 10

Motherboard no longer works
by Ryan Carboni 30 Jun '19

30 Jun '19

My desktop motherboard no longer works (after they borked two Windows installations, they decided to bork my Fedora installation). Regardless, I have performed a UEFI backup of the settings, so I believe that any evidence of tampering will be on the second ROM chip. I will keep you guys posted if the government will attempt to recover or cover up their ... I guess they would tell a judge it is tools? Sent with [ProtonMail](https://protonmail.com) Secure Email.

1 0

There can't be a deep state
by Ryan Carboni 29 Jun '19

29 Jun '19

Listened to a podcast once, where someone said, "I wish there was [a deep state]" There can't be a deep state. If there was, how could they botch something as salacious as MLK engaging in an orgy involving "natural and unnatural acts"? Sent with [ProtonMail](https://protonmail.com) Secure Email.

1 0

Fake Satoshi
by John Newman 29 Jun '19

29 Jun '19

https://www.bloomberg.com/news/articles/2019-06-28/self-proclaimed-bitcoin-…

1 0

Trump To Ban All Crypto, NSA Lies Collects Calls Anyway, US Roots Yandex
by grarpamp 29 Jun '19

29 Jun '19

https://www.politico.com/story/2019/06/27/trump-officials-weigh-encryption-… https://gizmodo.com/trump-white-house-reportedly-debating-encryption-policy… According to a report in Politico, the Trump administration held a National Security Council meeting on Wednesday that weighed the challenges and benefits of encryption. "One of Politico's sources said that the meeting was split into two camps: Decide, create and publicize the administration's position on encryption or go so far as to ask Congress for legislation to ban end-to-end encryption," reports Gizmodo. From the report: That would be a huge escalation in the encryption fight and, moreover, would probably be unsuccessful due to a lack of willpower in Congress. No decision was made by the Trump administration officials, Politico reported. The White House did not respond to a request for comment. The fact that these discussions are ongoing both within the White House and with Silicon Valley shows that the issue is still very much alive within the corridors of power. https://www.usatoday.com/story/news/nation/2019/06/26/nsa-improperly-obtain… The National Security Agency improperly collected phone call records of Americans last fall, months after a previous breach that compelled the agency to destroy millions of records from the contentious program, documents released Wednesday revealed. The redacted documents, obtained by the ACLU in a Freedom of Information Act lawsuit, do not indicate how many records NSA improperly collected in the October breach, nor which telecommunications provider submitted the improper data. "These documents provide further evidence that the NSA has consistently been unable to operate the call detail record program within the bounds of the law," the ACLU said in a letter to Congress this week lobbying for an end to the program. The letter says elements within the Office of the Director of National Intelligence concluded the October violations had a "significant impact" on privacy and civil rights, but that the Americans affected were not told of the breach. https://www.reuters.com/article/us-usa-cyber-yandex-exclusive/exclusive-wes… The malware, called Regin, is known to be used by the "Five Eyes" intelligence-sharing alliance of the United States, Britain, Australia, New Zealand and Canada, the sources said. Intelligence agencies in those countries declined to comment. Western cyberattacks against Russia are seldom acknowledged or spoken about in public. It could not be determined which of the five countries was behind the attack on Yandex

1 0

cypher punks bow - the literal (tech + social) Great Charlottesville Hack of 2018"
by Zenaan Harkness 29 Jun '19

29 Jun '19

One awesome hack - both tech and social enginerring, so kudos Weev - a serious badass political (ultimately) hack! The Great Charlottesville Hack of 2018: A Message to the People of Charlottesville https://dailystormer.name/the-great-charlottesville-hack-of-2018-a-message-…

1 1

8 million YouTube "holocaust denial" videos genocided, and counting - Oy vey! it's anuddah shoah! - [PEACE]
by Zenaan Harkness 29 Jun '19

29 Jun '19

Everybody's fav NSA money munkey junkies are layin' itall out in public for ya - we just LOVE tha smell o TubeCoin bannin's in the mornin... Booh yeah muffaluggerahs, keep on pimpin your Souls :D YouTube: We Will Genocide Any Video Denying the 'Holocaust' https://russia-insider.com/en/youtube-we-will-genocide-any-video-denying-ho… http://americanfreepress.net/youtube-inquisitors-demolish-history/ “Though justified by liberal Silicon Valley oligarchs as a response to the “racism, sexism, and homophobia” of the alt-right, YouTube’s new censorship plan begins with garden-variety political correctness—and ends in the wholesale falsification of history.” Dr. Kevin Barrett Tue, Jun 25, 2019 The original headline of this article was: YouTube Inquisitors Demolish History During the first week of June, YouTube announced a draconian new censorship policy—and immediately erased or demonetized the work of countless video-makers, destroying thousands of livelihoods in the process. Conservatives bore the brunt of the onslaught. The new policy was unveiled in the wake of a highly publicized spat between conservative YouTuber Steven Crowder and “Vice News” commentator Carlos Maza, in which Maza accused Crowder of “bullying” and “homophobia.” [img] “The YouTube Inquisitors: Eight million "unsuitable" videos erased and counting!” Though justified by liberal Silicon Valley oligarchs as a response to the “racism, sexism, and homophobia” of the alt-right, YouTube’s new censorship plan begins with garden-variety political correctness—and ends in the wholesale falsification of history. In a June 5 blog post announcing the new policy, YouTube wrote: Today, we’re taking another step in our hate speech policy by specifically prohibiting videos alleging that a group is superior in order to justify discrimination, segregation or exclusion based on qualities like age, gender, race, caste, religion, sexual orientation or veteran status. This would include, for example, videos that promote or glorify Nazi ideology, which is inherently discriminatory. Finally, we will remove content denying that well-documented violent events, like the Holocaust or the shooting at Sandy Hook Elementary, took place. The first two sentences sound like a well-meaning but maddeningly muddled mishmash of liberal platitudes. Taken at face value, YouTube is telling us we cannot “allege” that adults are intellectually superior to children and that children should therefore be segregated or excluded from busy streets. Or that 20-year-olds are more physically vigorous than retirees and should be excluded from over-60 basketball leagues. Age discrimination! Or that men are physically stronger than women and should therefore be excluded from women’s athletics. Gender discrimination! Anti-LGBTQ discrimination! Or that poorer people and groups, being in general less capable in intellectual and practical matters than wealthier people and groups, should be given various advantages like free college tuition as part of a policy of reducing inequality. Race and caste discrimination! Or that veterans, having been willing to risk their lives for their country, deserve special benefits. Pro-veterans discrimination! ... "So long, and thanks for all the #fashtags" perhaps?

1 0

Trendline to Zero
by Ryan Carboni 29 Jun '19

29 Jun '19

First the government harassed me and claimed it wasn't happening, going so far as to put me into the strange mid-ground between a mental health hold and arresting me. Then they claim that... what? It was an elaborate long term plan? I outright say the government is harassing me... and they are. And the government is lying about it. The government likes to brag it has capabilities, but the problem is that they hire stupid people. You have to be stupid not to see the US as corrupt, while having access to all that they do. The government is trying to outsmart me. It has immense resources, and it is failing horribly, even though I am just one person, systematically isolated (no incriminating metadata though, right?), and is failing. Every time. And I can say this because the government brags that it is doing it, so they have to create a parallel investigation every few months to find something new to pin on me. And then I ruin the parallel investigation because apparently only a genius can understand that "any intelligent fool can make things bigger, more complex...". I demand my own freedom. The government says no. The stakes are too stupid for this to continue, and yet it does. The government is able to lie, yes. The government is self-aware that some actions are unpopular yes. The government believes it is executing the will of the people. Um. To quote a previous email from me: On a side note, what is the legal culpability of someone who wasn't on the radar of an investigation, is alleged to be involved by a third party already admittedly unreliable due to lies, as a result, the first party faces the full brunt of an investigation for a decade while the third party goes off scott free? This is one of self-evident impropriety things. What was the motivation for focusing immense resources on me? Because some psychologist in the Behavioral Analysis Unit thought I was most likely to crack? I wasn't involved. The government made me involved. There is no metadata. I demand the government to disclose the facts. The government believes it is representative, and so it conceals the truth. And so I post this, yet the government has no real reaction? I think I should go further, the government is intimidated, and so it must engage in secrecy. Sent with [ProtonMail](https://protonmail.com) Secure Email.

3 2

Re: Google bias exposed...
by Punk 28 Jun '19

28 Jun '19

On Fri, 28 Jun 2019 01:10:16 +0000 (UTC) jim bell <jdb10987(a)yahoo.com> wrote: > > You are writing as if what you, personally, think you need (or don't need) somehow applies to everyone else. Stop making things all about you. uh oh - you accussed ME of defending google - you set the topic. > You said: > "I made it pretty clear that I don't need any 'software' telling me that google-NSA-GCHQ is just a propaganda outlet for "american govcorp"." > Why should anyone else find that what YOU need is sufficient for them too? I didn't say they should. My point is that anybody who did their homework should know what google is. And what the rest of the silicon valley fascist cesspool is. And what american govcorp is. Et cetera. now, if you don't mind, explain how a text parser is going to detect 'political bias'? BUT WAIT, do you want to create some sort of website where people can allegedly check if other sites are 'biased'? And people should 'trust' YOUR site, WHY exactly?

2 2