Local solutions: SKS Keyserver Network Under Attack

[Roland]

Dear Forum,

GNUPG Users Digest is nearly flooding my mailbox with exchanges about 
the WoT and keyserver issues.

A simple user (me) needs to know how one could make adaptations in the 
settings of GPA or Kleopatra. I would expect instructions here:
https://kde.org/applications/utilities/org.kde.kleopatra
www.gnupg.org/related_software/gpa/
or perhaps here:
www.gpg4win.org/index.html
www.enigmail.net/index.php/en/
*There are not.*

Hansen's and DKG's blog are only partly helpful. For example my Linux 
system seems to *not* have a  ~/.gnupg/dirmngr.conf file at all (one of 
those files recommended for editing). I.e. Nautilus cannot find it.
So, I did adapt gpg.conf by outcommenting (#) any line starting with 
keyserver, but was not able to adapt the dirmngr.conf.
Upon inspection, thereafter, my GPA and Kleopatra were NOT correctly 
configured.

Trying to figure out how GPA and Kleopatra could be adapted, I found, 
for GPA: Menu > Edit > Backend preferences > Network > Configuration for 
Keyservers > Use custom value > adapt to hkps://keys.openpgp.org
For Kleopatra: Menu > Settings > Configure Kleopatra > Directory 
Services > Open PGP Keyserver > adapt to hkps://keys.openpgp.org
(I would have included an inline screenshot, but this list is allergic 
to html)

GPG4Win and Enigmail need further research. (This is a suggestion. I 
cannot do it).

And further, I would have expected a program update that sets the 
defaults to the ones suggested by Hansen and DKG. Or is the matter still 
under consideration, or is it not that important? (I personally cannot 
judge it).

The only hint that I can give: The WoT nor keyservers are not very 
important in my case. I use GnuPG inside a small group of people who 
(for identity verification) can talk to each other, at least by 
telephone. I do not use Enigmail (since limited to few mail clients and 
not accepted by sufficient of my recipients), but just send encrypted 
messages as attachments.

Best regards

Roland


On 02/07/2019 05:48, gnupg-users-request at gnupg.org wrote:
> Send Gnupg-users mailing list submissions to
> 	gnupg-users at gnupg.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.gnupg.org/mailman/listinfo/gnupg-users
> or, via email, send a message with subject or body 'help' to
> 	gnupg-users-request at gnupg.org
>
> You can reach the person managing the list at
> 	gnupg-users-owner at gnupg.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Gnupg-users digest..."
>
>
> Today's Topics:
>
>     1. Re: Your Thoughts (Stefan Claas)
>     2. Re: SKS Keyserver Network Under Attack (Alyssa Ross)
>     3. Re: Your Thoughts (Alyssa Ross)
>     4. Re: New keyserver at keys.openpgp.org - what's your take?
>        (Mirimir)
>     5. Re: Your Thoughts (Robert J. Hansen)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 2 Jul 2019 00:09:47 +0200
> From: Stefan Claas <sac at 300baud.de>
> To: gnupg-users at gnupg.org
> Subject: Re: Your Thoughts
> Message-ID: <mailman.15908.1562039285.30381.gnupg-users at gnupg.org>
> Content-Type: text/plain; charset=utf-8
>
> Ryan McGinnis via Gnupg-users wrote:
>
>> Null modem transfer of your messages?  Yikes.  To me that?s the issue with
>> PGP in general as it relates to secure communications - the nerds and the
>> criminals and the spies know how to work it, but your average end user
>> doesn?t need their step one to be ?go to a Goodwill in a city you don?t live
>> in wearing a disguise and buy a laptop with cash?, they need PGP to almost be
>> automatic.  Think of how easy it is to bootstrap Signal and how hard you?d
>> have to try to accidentally send something cleartext over that application.
>> Linking your key to a new device is as easy as scanning QR code. Perfect
>> forward secrecy, rich media, voice and video synchronous communications
>> upgrades, you name it.  And my grandma could probably set it up without
>> help.  I guarantee most big data scooping intelligence services are a lot
>> more worried about OpenWhisper protocol than PGP because *people actually use
>> it*.  Just being caught with WhatApp in China can get you sent to a camp,
>> depending on your ethnicity.
> Not to be off-topic, but you gave me the keyword "China" ...
>
> I just recently found this and was wondering what purpose it
> serves? Are people in China also allowed to use GnuPG?
>
> pgp.ustc.edu.cn/
>
> Regards
> Stefan
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 1 Jul 2019 22:43:18 +0000
> From: Alyssa Ross <hi at alyssa.is>
> To: Mirimir <mirimir at riseup.net>
> Cc: gnupg-users at gnupg.org
> Subject: Re: SKS Keyserver Network Under Attack
> Message-ID: <20190701224317.x3mffnm63klnxcyg at x220.qyliss.net>
> Content-Type: text/plain; charset="us-ascii"
>
>> And yes, hkps://keys.openpgp.org would fall over and die if too many
>> users started using it. So cert poisoning will be an issue until there's
>> a secure alternative.
> Just as a point of interest, I've talked to the people running
> keys.openpgp.org about their capacity in #hagrid, when we were exploring
> whether to change the default keyserver in Nixpkgs' GnuPG[1] (which we
> ended up doing).
>
> The impression I got was that they're very optimistic about their
> ability to handle traffic to their server -- they were happy to have a
> distro make the switch, and will be changing the defaults in Enigmail
> and OpenKeychain very soon, as I understand it.
>
> It is a real shame that a decentralized Hagrid isn't really possible,
> though, at least to my understanding. It's quite the limitation for
> GnuPG.
>
> [1]: https://github.com/NixOS/nixpkgs/pull/63952
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 833 bytes
> Desc: not available
> URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190701/4589554b/attachment-0001.sig>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 1 Jul 2019 22:58:32 +0000
> From: Alyssa Ross <hi at alyssa.is>
> To: Stefan Claas <sac at 300baud.de>
> Cc: gnupg-users at gnupg.org
> Subject: Re: Your Thoughts
> Message-ID: <20190701225832.6oldo4pexgjuy6yy at x220.qyliss.net>
> Content-Type: text/plain; charset="us-ascii"
>
>> I think also (sorry to say this Werner!) the problem is that
>> GnuPG is Linux cli based and not like MacPGP from Mr. Zimmermann,
>> back in the 90's was GUI based with much lesser commands and
>> easier to learn. There was back then no Enigmail or other
>> MUA plug-ins and you could simply copy and paste your messages.
> GnuPG is cross-platform and in no way tied to Linux, but I think you
> have a point about the CLI-focused design of it. The problem isn't that
> it's CLI-based per se, but that this design has made it far too easy for
> it to accumulate features without much consideration for how the whole
> thing works together.
>
> For example, why isn't ask-cert-level a default? I'm guessing it's just
> because at some point it didn't exist, and the developers didn't want to
> make a backwards incompatible change. But it means that, out of the box,
> signatures on other keys are next to useless, because it's not possible
> to specify how carefully you've checked a key. This leads to people only
> signing keys that they've very carefully checked, and makes it so that
> marginal signatures see almost no use, which I think has likely been a
> major contributor to the failure of the web of trust.
>
> A large part of what makes alternative encryption software like Signal
> successful is its simplicity. I don't have to worry about the 3000
> different setting combinations available to me, because there's design
> work been put into it to set me up for success out of the box. I've
> spent hours of my life learning about how to use GnuPG, and have ended
> up with a way of using it that seems completely different to anybody
> else's, but I still don't think I'm doing it right. It's not possible to
> figure out how to use it as intended, because there's no intended way to
> use it. There's no high level design for how people are supposed to use
> the software. And without that, it's never going to be possible to use
> GnuPG properly no matter how much time one is willing to invest.
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 833 bytes
> Desc: not available
> URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190701/ed0d6216/attachment-0001.sig>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 1 Jul 2019 19:44:04 -0700
> From: Mirimir <mirimir at riseup.net>
> To: gnupg-users at gnupg.org
> Subject: Re: New keyserver at keys.openpgp.org - what's your take?
> Message-ID: <4c4a0cab-5fae-5351-6b88-6f363032f290 at riseup.net>
> Content-Type: text/plain; charset=utf-8
>
> On 07/01/2019 07:29 AM, David wrote:
>
> <SNIP>
>
>> My take on all this is that I have had to disable Enigmail because it's
>> screwed - I was not able to send mail and all the settings in enigmail
>> were lots of ???????????? so I have been infected :(
>>
>> David
> Damn. But all is likely not lost.
>
> If you can open Enigmail Preferences, go to the Keyserver tab, and
> specify only keys.openpgp.org as the keyserver. That way, if you manage
> to fix gpg, Enigmail won't break it again. Also see "100% CPU usage
> endles loop of gpg --list-keys" <https://dev.gnupg.org/T3972> for
> background.
>
> About hardening and fixing gpg, see
> <https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f> at
> Mitigations and Repairs. Also see
> <https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html>.
>
> You'll very likely need to use gpg in terminal. I suspect that GPA may
> be just as wedged as Enigmail.
>
> Maybe someone could post a step-by-step guide for fixing gpg. For people
> who don't commonly use it in terminal. I suppose that I could import one
> of the poisoned keys in a fresh VM, and explore how to fix it. But I'm
> sure that someone reading this could just dash it out.
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 1 Jul 2019 23:47:56 -0400
> From: "Robert J. Hansen" <rjh at sixdemonbag.org>
> To: gnupg-users at gnupg.org
> Subject: Re: Your Thoughts
> Message-ID: <30ca199b-1087-4439-2dc8-b46401179380 at sixdemonbag.org>
> Content-Type: text/plain; charset=windows-1252
>
>> GnuPG is cross-platform and in no way tied to Linux, but I think you
>> have a point about the CLI-focused design of it. The problem isn't that
>> it's CLI-based per se, but that this design has made it far too easy for
>> it to accumulate features without much consideration for how the whole
>> thing works together.
> Eh.  Yes, no.  I agree with the claim that GnuPG's "we-do-it-all"
> approach is overall a net negative for security: but there's a strong
> argument to be made that if GnuPG didn't do it all, it wouldn't get done
> at all.
>
> Remember that for about fifteen years GnuPG received basically nil for
> funding.  For a long while each Christmas I'd run a fundraiser match for
> GnuPG, where I'd match dollar-for-dollar every dollar donated to GnuPG
> for development.  My donation capped at $500.  For several of those
> years, I was one of the largest individual contributors to GnuPG.
>
> During that long period when GnuPG was short of funds and developers, it
> could have focused on just one part of the crypto puzzle.  "This will
> verify operating system packages with OpenPGP" or "this will verify
> emails with OpenPGP", to use one simple distinction.  But doing that
> would've left the other, just as important, need unaddressed: so the
> developers did their best to make one package be useful to as many
> OpenPGP users as possible.
>
> This approach created some problems.  Some of the Efail bugs were
> created when GnuPG generates output data even though the file fails
> integrity checks.  This is not behavior you want in an email crypto
> engine: if the email fails, you want to just bomb out and create no
> data.  But this *is* behavior you want in a bulk crypto engine, where
> there is no reasonable way to store petabytes of encrypted data in RAM
> to check for consistency before writing to disk.
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
>
> ------------------------------
>
> End of Gnupg-users Digest, Vol 190, Issue 11
> ********************************************
>
>