Re: SKS Keyserver Network Under Attack
*ahem* https://github.com/aestetix/pgpfs And the talk where I released it: https://www.slideshare.net/aestetix/berlinsides2017 On Mon, Jul 01, 2019 at 08:18:25PM +, John Newman wrote: On July 1, 2019 3:03:25 AM UTC, Mirimir wrote: On 06/30/2019 07:40 PM, John Newman wrote: I'm surprised no one has written an sks filesystem (using fuse maybe), although it would obviously be horribly inefficient, and a total abuse of the system. They have: https://github.com/yakamok/keyserver-fs ;) Ack, I should've known ;) I'm not nearly evil enough to start playing with that code... signature.asc Description: PGP signature
Re: SKS Keyserver Network Under Attack
‐‐‐ Original Message ‐‐‐ On Monday, July 1, 2019 8:18 PM, John Newman wrote: > ... > > They have: https://github.com/yakamok/keyserver-fs ;) > > > > Ack, I should've known ;) I'm not nearly evil enough to > start playing with that code... evil is mapping the storage to > 100k certs per popular key ids. :P
Re: SKS Keyserver Network Under Attack
On July 1, 2019 3:03:25 AM UTC, Mirimir wrote: >On 06/30/2019 07:40 PM, John Newman wrote: >> I'm surprised no one has written an sks filesystem (using fuse >maybe), although it would obviously be horribly inefficient, and a >total abuse of the system. > >They have: https://github.com/yakamok/keyserver-fs ;) > > Ack, I should've known ;) I'm not nearly evil enough to start playing with that code... signature.asc Description: PGP signature
Re: SKS Keyserver Network Under Attack
On 06/30/2019 07:40 PM, John Newman wrote: > I'm surprised no one has written an sks filesystem (using fuse maybe), > although it would obviously be horribly inefficient, and a total abuse of the > system. They have: https://github.com/yakamok/keyserver-fs ;)
Re: SKS Keyserver Network Under Attack
I'm surprised no one has written an sks filesystem (using fuse maybe), although
it would obviously be horribly inefficient, and a total abuse of the system.
On June 30, 2019 10:40:20 PM UTC, coderman wrote:
>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
><[r...@sixdemonbag.org](mailto:r...@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 (j...@example.org) and I (r...@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
>(h...@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 cho
SKS Keyserver Network Under Attack
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
<[r...@sixdemonbag.org](mailto:r...@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 (j...@example.org) and I (r...@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 (h...@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 o
