Re: Local solutions: SKS Keyserver Network Under Attack

[Mirimir via Gnupg-users]

On 07/03/2019 10:19 PM, Mirimir wrote:
> Moved by Roland's requests, I've broken Enigmail in a fresh VM. And I'd
> appreciate some advice about how to fix it.
> 
> I installed Thunderbird and Enigmail in a Debian 9.5 x64 VM with Gnome.
> Using Enigmail Key Management, I tried to get rjh's 1DCBDC01B44427C7
> from pool.sks-keyservers.net, but that just timed out.
> 
> So I downloaded it via HTTPS. And it was ~60MB. I tried importing from
> the downloaded file, but that went nowhere. With 100% CPU.
> 
> So I got it from https://keybase.io/rjh and imported from clipboard in
> Enigmail Key Management. That worked just fine. So then I tried
> refreshing keys in Enigmail, leaving pool.sks-keyservers.net as the
> default keyserver. And that failed, complaining about no dirmngr. Then I
> tried refreshing keys with gpg in terminal, and got the same error about
> no dirmngr.
> 
> Then I deleted rjh's key, and got my own from Keybase, and imported it.
> But when I tried refreshing keys, I got the same error about no dirmngr.
> 
> So gpg must still work, because I can import and delete keys via
> Enigmail. But something seems borked about dirmngr. I guess that I'll
> try purging and reinstalling. Or is there a better fix?

Damn. Somehow dirmngr didn't get installed with Thunderbird and
Enigmail. How embarrassing. So now Enigmail does refresh my key.

But after importing rjh's key, refreshing in Enigmail fails:

| Downloading of keys failed
| gpg: keyserver receive failed: No data

I also tried in terminal:

| user@debian:~$ gpg --refresh-keys
| gpg: refreshing 2 keys from hkps://hkps.pool.sks-keyservers.net
| gpg: key ...: 22 signatures not checked due to missing keys
| gpg: key ...: "mirimir " not changed
| gpg: Total number processed: 1
| gpg:  unchanged: 1

Then I disabled rjh's key, and found that my key still refreshed
quickly. Using hkps.pool.sks-keyservers.net.

So that's good news, yes? Trying to refresh rjh's key failed, but it
failed quickly, and the attempt apparently didn't break anything.

> And yes, I should have tested everything first with a clean key, before
> messing with rjh's key. Is it likely that I borked dirmngr during the
> intital attempt to get it from pool.sks-keyservers.net?
> 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Your Thoughts

[Mirimir via Gnupg-users]

On 07/03/2019 07:16 AM, Ryan McGinnis via Gnupg-users wrote:
> Not sure why the phone number thing bothers people -- having a
> phone at all in the first place means you are easily tracked.

Well, that's why I only use phones (and not smartphones) for routine
meatspace stuff where I don't care about privacy. If the NSA wants to
know about my dental appointments, fine.

> What Signal (and any encryption system, really) does is try to
> prevent in-transit interception and surveillance of the actual
> data content.  It can't hide the metadata associated with a layer
> well above the application layer.

You're missing the point. Signal not only doesn't hide network-level
metadata, it embeds it in the content. As the bloody account ID.

I mean, I'm sitting here at a computer. It has lots of firmware IDs, a
MAC address, and a public ISP-assigned IP address. But none of that
stuff, unless I am sadly mistaken, shows up in my online activity. In
the headers of this message, for example. Because I use nested VPN
chains, plus Tor when I really want some anonymity.

So the equivalent here to Signal would be that my email address had to
be associated with my ISP-assigned IP address. And for sure, that's how
it was 20 years ago, when I used an email address from my ISP. I used
PGP for content privacy, but there was zero anonymity.

So how is that bullshit acceptable in 2019?

> Openwhisper can be picked up at the firewall level, but then so
> can Tor and VPN spinups, and all of these things are metadata
> that make you score more interesting to the mass-data-scoop
> algorithms.  If you don't want to be easily geo-locationally
> tracked, don't use a device with a cellular modem, full stop.  

Sure. But I can start with a popular VPN, and maybe 20% of people around
me use VPNs for pirating, so that's not too unusual. What's unusual is
what I route through that VPN. But even discovering that would take some
work, and then they'd just see another VPN. The won't see Tor until they
drill down 3-4 VPNs.

It's not just cellular modems that enable geolocation. There's GPS. And
there are databases with locations of WiFi APs. If it were possible to
securely use VPNs and Tor on smartphones, geolocation wouldn't be any
more of an issue than it is for me, sitting here at my computer.



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS and GnuPG related issues and possible workarounds

[Ryan McGinnis via Gnupg-users]

To be fair, that bookshelf got pointed out like a decade ago. It’s just that 
resources to build a new one never materialized.

While pointing out a problem by doing a targeted demonstration attack is about 
as aggressively black hat as it gets, it’s hard to not expect it. Even big 
white hat boys like Project Zero give 90 days to fix an issue before publishing 
(and once published, you can assume the exploit will be used in the wild.) 
Pining for a simpler time when people didn’t try to exploit other people and 
systems is silly because those times never existed - it’s just that there 
didn’t use to be such significant value attached to software systems so the 
only people who carried out attacks were nerds doing it for the lulz. (Well, 
the ROTFLs back then, I guess.) Sure, nobody could anticipate contemporary 
attacks a decade ago, but that seems more a cautionary tale against allowing 
non-serviceable abandonware to run critical systems. If any 15 year old script 
kiddie can easily bring your whole global heavily relied-upon system down, then 
having someone pull back the curtain on the wizard seems like an understandable 
choice, even if it’s a bit of a jerk move.

But yeah, that said — don’t kick the bookshelf over. :) Just hope that in the 
meantime nobody figures out a way to profit or benefit somehow from doing so.

-Ryan McGinnis
[https://bigstormpicture.com](https://bigstormpicture.com/)
PGP: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD
Sent with ProtonMail

On Wed, Jul 3, 2019 at 09:18, Andrew Gallagher  wrote:

> On 03/07/2019 15:00, Stefan Claas via Gnupg-users wrote:
>> If I had time and money I would hire a lawyer, would formulate a letter
>> for SKS operators stating that I request the removal of my pub key data
>> and would as EU citizen refer in this letter to our GDPR.
>>
>> Maybe, if time allows, I may check with EFF and their lawyers ...
>
> Would you mind waiting for the replacement system to be fully tested and
> migrated before setting fire to the old one?
>
> There's a scene in the classic comedy Father Ted, where a visitor to the
> parochial house starts complaining about the build quality of the
> bookshelves, and to prove his point he pulls them to pieces. "Look at
> that, it's falling apart!" [1]
>
> Just because something is broken does not mean you are obliged to kick
> it over to prove the point.
>
> [1] https://vimeo.com/108169770
>
> --
> Andrew Gallagher
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users-BEGIN PGP PUBLIC KEY BLOCK-
Version: Pmcrypto Golang 0.0.1 (ddacebe0)
Comment: https://protonmail.com

xsFNBFoywpoBEACGlCLzuIxPtuT60BWw+YnCEw5/GlXIx5X6l3NJgDiT/Qrv6m3C
X4NJEHcmUOruIhR/bI0WkvuWV4Rfxv0BKQjp7JnMWRDOY5NxIckvMJGplLThcyRj
KqAvixSruksxt3v3A5b77Kyw1eyB3+eC3Yo0g28yhhfln1gexzsUsuzSW+Fixxgz
S2KdJ26aZ8Sb3gjvfHLv/MKhXluSwYgXIDKMiUOib0iDVdWPfFXCpVbH3o18VnxT
dC3UI3vVmlJarR4O5xIp6FwdmQVtj73ZMHdgYnQceGYcwob8taO0dKfU+31/bjuu
MaOjy2uKnCx9leeK4H13JcbIyGSK7jrAeQRNwE58UzBJZUBs1IDcdYY7Yv1ob9iM
YcfkZhqzztDjK1QP3Ibe3AG02X+rUXLcvlh8EccDb/W50IA+ejDy7yFQb6SK+4Sp
IrZHGPjf1yD4xkkhzNFPJ2mYGN4hCCrnWrDg/hC3rxSwCpI3PExlZ8OF9jy9jTtq
IRx/zXSQKgJcADs4tsNHfzPrnEy41bsmcdI0NrncPcf25jFvaPTwBHACyHlmFX2z
/GuCheopaxmiVJFuVleqrtxeTBN4v79LhxBGtCUdYH9GrenFvzA9v8VMA6r9d7aW
Cb7l0JHL8wzDBOlDCbJMZvT7tDxyl2MIv11LQeIInRlI6JBxLCFZuhYPzwARAQAB
zSVyeWFuQGRpZ2ljYW5hLmNvbSA8cnlhbkBkaWdpY2FuYS5jb20+wsF1BBABCAAp
BQJaMsKgBgsJBwgDAgkQtao/o0hu160EFQgKAgMWAgECGQECGwMCHgEAAJyLD/0T
eGFbbuNyPflTosdmmKAC6ZyuDwJxLjvL3YnHAUPkTO/a6xTtEZ2B41/mOx2OTcyh
JhhwtB0/lsSN7r5rXHzUW4Ve6GSS8PEI3j1IyM/wecv3+gb38ffdFEJA1bUn9+f/
uyhQIFaLwFpq8UQGxDRJ91QXcXFrPzalsv9KKNct1tRClfVnQR77BzkhfIJs2gQi
yT1l+VFqzXAhViiuzRdlJMaTLb236UkeOx/eyNVEcivVYouy2BzL/dW28WDPPtdV
HOcVmV4KfaYJpH4mBHB/KP+JNQy5spVfMLMfC08r5a0EFE3Byeblt3ONPm+2ymzC
RotItz8T7scwu4xTmIw5WWRcIi3mbDW/mefo7whbX3o7NidPBC+ZqJsqLoNno/aD
PYXnpTzAbs4UTSqp6P49MHVWNF4/n/aXU3VhBvZx0h1NNNbO1PzR/8Sr7fedD9UC
niJNJgfaKht1i19Pc+BF5+sgnbRZeIfSxHWfXD+krIWGZmRBaBpGzR3Jr3AAwCcD
uJVeCXxIe17ZTHywqVZloXFXERJBTfmJ+ADn2+sFMjpdWBawsl5xX/9ffiOYf8i0
lGh6vkikBnGZznXIZxcv/IViHugbV73qpvKTiZb0NhX9awy2lbjqdqg4xPxn2RIo
phF9U3iblap4jJrY0Z66gMPHAoeUZUIkW+Z63OPIlM7BTQRaMsKaARAAiRnZm4uc
PKsFDPnMJ5VqEdxOKqTalk1D37712zj/Z7069ZFEzBv9RETqOjvaBCVTtLkZjUKu
At9AQwKJkqHMmzGTglTkyq8D3Fwp11yUhBmv3yOr+0V5MeE69HMuqitpO5gXmoM1
2CUAPDsqet8F8LstEJMbRhpxvOsgmMRWgFm5L74cyqOT44+Mo8+uLwevPH1pC7bE
/kLEPewcAE/60pQ0YgVP2Le6x2ht8CzDZ7p8cSHkXlBa9yHkXZREtU+L0WIIM+3o
F0rrxLxCirbcShN3ZExx+kLnM2zb3xmEQwY6bwlUtHknnoVpJkZXPc3mNJQKc084
+XGgIcPaq053vpIZkOwfQboovk6xpolZGfSnxsQSVsBLT7XYJGe2v4StLnKU3G1W
MIhy8N+s+P+PtOc+YEOl5/6rhbeI6RAlKmpr+/0hEXoe+FxQ+t679M/dGjmFc5bR
TYtoY6bZnhjGbvtuf4+zfPSnvaL8Qmwdcn6XHQ1VwBBaUYyjaLIL+NjmKJ7RXhkk
2yK4IMbd5X0YuL5fuZgMq99BSnEmgPtAHpAokr/lYutUo66hHPD99iAIL1aB9iNe
jjSAcub5A8P0CZabMMelvl9BtWDeGgGz+yEBiI7OL8wZ9Lg634E6Q65HRfAqAbSg
sJrFdGsKJ3snQtalbzS2AjWURvV9nShznWsAEQEAAcLBXwQYAQgAEwUCWjLCowkQ
tao/o0hu160CGwwAAN

Re: Local solutions: SKS Keyserver Network Under Attack

[Mirimir via Gnupg-users]

Moved by Roland's requests, I've broken Enigmail in a fresh VM. And I'd
appreciate some advice about how to fix it.

I installed Thunderbird and Enigmail in a Debian 9.5 x64 VM with Gnome.
Using Enigmail Key Management, I tried to get rjh's 1DCBDC01B44427C7
from pool.sks-keyservers.net, but that just timed out.

So I downloaded it via HTTPS. And it was ~60MB. I tried importing from
the downloaded file, but that went nowhere. With 100% CPU.

So I got it from https://keybase.io/rjh and imported from clipboard in
Enigmail Key Management. That worked just fine. So then I tried
refreshing keys in Enigmail, leaving pool.sks-keyservers.net as the
default keyserver. And that failed, complaining about no dirmngr. Then I
tried refreshing keys with gpg in terminal, and got the same error about
no dirmngr.

Then I deleted rjh's key, and got my own from Keybase, and imported it.
But when I tried refreshing keys, I got the same error about no dirmngr.

So gpg must still work, because I can import and delete keys via
Enigmail. But something seems borked about dirmngr. I guess that I'll
try purging and reinstalling. Or is there a better fix?

And yes, I should have tested everything first with a clean key, before
messing with rjh's key. Is it likely that I borked dirmngr during the
intital attempt to get it from pool.sks-keyservers.net?

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Phil Pennock via Gnupg-users]

On 2019-07-03 at 09:17 +0100, Andrew Gallagher wrote:
> I didn't even know it supported finger URLs - handy to know! Opening a
> finger port may be a step too far for the security-conscious though...

Depends upon the implementation.  I'm biased here, I wrote my own in
Go back in 2016:  https://go.pennock.tech/fingerd/

See the AttackSurface.md doc therein too.

That provides the finger service for @spodhuis.org ... using the FreeBSD
port 1079 example configuration.  A packet filter redirects port 79 to
the correct port in the Jail which lacks outbound network connectivity
except via NAT state for established connections.

-Phil

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Ángel]

On 2019-07-02 at 10:01 +0200, Wiktor Kwapisiewicz wrote:
> > 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.
> 
> Decentralized non-identity information hagrid could still be
> possible. 
> It's just a question over which protocol to synchronize this kind of
> data.

A point I don't like about the design of hagrid is that verification is
performed by the server itself.
Thus, it seems that if there were a reconciliation protocol between
them, either entering into one of them would lead to all of them blindly
trusting it, or the owner would need to validate a challenge for each
keyserver to which it gets replicated.

My expectation would be that the verification added a (non-dropped)
signature by the entity which performed the verification.
The keyservers themselves would be configured with a set of introducing
keys whose signatures they accepted for non-stripping.

This way, multiple servers, managed by different individuals, could rely
on a common verification entity (which may not run a keyserver itself).

The current reconciliation protocol (ie. the one used by SKS) would
probably work if all keyservers in a network trusted the same
verification keys, as they would share the same view.
(I admit my utter ignorance of the gossip protocol, though)

It would be desirable that it worked even with separate ones, so eg.
gentoo could use a single server that allowed its own CA and
keys.openpgp.org, even if the later only trusted its own verifier.

Unpublishing of uids would simply be triggered by the publication of the
revocation signature.
This is akin to other systems, like the old "PGP Global Directory Verification
Key" signatures.

I see on https://sequoia-pgp.org/blog/2019/06/14/20190614-hagrid/ that a 
machine-readable vouch was not added since "we don’t think that the 
verification 
is strong enough to even warrant a positive certification". However, I do think
that will be needed in order to have a successful keyserver network, and it 
would
be helpful to separate both roles.
They could be made at the persona cert level (1), to make gpg ignore them (by 
default), though, as a way to disincentive treating them as a CA. 

Kind regards


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[raf via Gnupg-users]

Werner Koch via Gnupg-users wrote:

> On Wed,  3 Jul 2019 12:35, gnupg-users@gnupg.org said:
> 
> > problem but I have read RJH's article). It sounds like SKS servers can
> > handle these poisoned keys but GPG can't. That suggests that maybe GPG's
> 
> I think here is a misunderstanding.  Sure, processing 150k signatures
> takes quite some time and makes things very slow.  This is why we call
> it a DoS.  We can't do much about it.  Compare it to X.509 CRLs - they
> have a very similar problem (cacert.org is a prominent but not the only
> example of CRLs making S/MIME processing very slow).
> 
> The actual problem in gpg when using the keybox format is that only
> after processing the imported keys we hit a 5MiB limit for the keyblock
> in the database layer.  Thus the import fails.  Determining the size of
> the keyblock as it will be stored requires that we first remove some
> (standard) garbage from the keyblock - this takes some time.  With the
> currently deployed code gpg will just reject any updates from a key if
> that limit was reached.  That is not a good choice and the reason why I
> call it a bug.   The fix to this bug is to fallback importing a stripped
> down version of the key.  The current state is that we keep only
> self-signatures and then then import again with import-clean (which is
> then basically identical to import-minimal).
> 
> > For example, if the problem is overuse of resources such as memory, could
> > the keyring handling code be rewritten to use fewer resources? e.g. treat
> 
> Years ago we had the problem that people uploaded keys with large user
> ids and such.  Thus we introduced limits to avoid spamming the keyring
> with such faked data.  There is also an overall limit of 5 MiB for the
> entire keyblock which is sufficient for all real-world keyblocks - even
> for those with many key-signatures.
> 
> > signatures when importing a key, perhaps there could be a limit to how many
> > signatures GPG will verify. Does it really have to verify every single one?
> 
> It needs to validate all self-signature because they make up the
> integrity of the keyblock.  For key-signature, sure we could introduce a
> limit, we actually do that with import-clean because that imports only
> those key-signature which we can verify and which are the latest from the
> same key (it is possible to sign a key several times to change meta data
> associated with the key-signature).
> 
> Salam-Shalom,
> 
>Werner
> 
> -- 
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

Hi Werner,

Thanks for the detailed explanation.
And thanks for gpg.

cheers,
raf


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Your Thoughts

[Wiktor Kwapisiewicz via Gnupg-users]

On 03.07.2019 20:30, Alyssa Ross wrote:

Oh, interesting. Thank you for showing this to me. I had it in my head
that a "weak" signature would count as a marginal in the web of trust,
but I suppose I was wrong about that.

In that case, I agree that ask-cert-level doesn't make sense as a
default.


I spent far too much time reading various OpenPGP resources so if you 
don't mind two articles that I particularly like:)


https://www.linux.com/learn/pgp-web-trust-core-concepts-behind-trusted-communication

and

https://www.linuxfoundation.org/blog/2014/02/pgp-web-of-trust-delegated-trust-and-keyservers/

The information density when I read them was definitely high for me but 
such articles are unfortunately very rare in this ecosystem.


Kind regards,
Wiktor

--
https://metacode.biz/@wiktor



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS and GnuPG related issues and possible workarounds

[Ryan McGinnis via Gnupg-users]

To be fair, that bookshelf got pointed out like a decade ago.  It’s just that 
resources to build a new one never materialized.  


While pointing out a problem by doing a targeted demonstration attack is about 
as aggressively black hat as it gets, it’s hard to not expect it.  Even big 
white hat boys like Project Zero give 90 days to fix an issue before publishing 
(and once published, you can assume the exploit will be used in the wild.)  
Pining for a simpler time when people didn’t try to exploit other people and 
systems is silly because those times never existed - it’s just that there 
didn’t use to be such significant value attached to software systems so the 
only people who carried out attacks were nerds doing it for the lulz. (Well, 
the ROTFLs back then, I guess.)  Sure, nobody could anticipate contemporary 
attacks a decade ago, but that seems more a cautionary tale against allowing 
non-serviceable abandonware to run critical systems.  If any 15 year old script 
kiddie can easily bring your whole heavily relied-upon system down, then having 
someone pull back the curtain on the wizard seems like an understandable 
choice, even if it’s a bit of a jerk move.  


But yeah, that said — don’t kick the bookshelf over.  :)  Just hope that in the 
meantime nobody figures out a way to profit or benefit somehow from doing so.  


-Ryan McGinnis
https://bigstormpicture.com
PGP: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD
Sent with ProtonMail

‐‐‐ Original Message ‐‐‐
On Wednesday, July 3, 2019 9:18 AM, Andrew Gallagher  
wrote:

> On 03/07/2019 15:00, Stefan Claas via Gnupg-users wrote:
> 

> > If I had time and money I would hire a lawyer, would formulate a letter
> > for SKS operators stating that I request the removal of my pub key data
> > and would as EU citizen refer in this letter to our GDPR.
> > Maybe, if time allows, I may check with EFF and their lawyers ...
> 

> Would you mind waiting for the replacement system to be fully tested and
> migrated before setting fire to the old one?
> 

> There's a scene in the classic comedy Father Ted, where a visitor to the
> parochial house starts complaining about the build quality of the
> bookshelves, and to prove his point he pulls them to pieces. "Look at
> that, it's falling apart!" [1]
> 

> Just because something is broken does not mean you are obliged to kick
> it over to prove the point.
> 

> [1] https://vimeo.com/108169770
> 

> --
> 

> Andrew Gallagher
> 

> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

To 


publickey - ryan@digicana.com - 0x5C738727.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Your Thoughts

[Leo Gaspard via Gnupg-users]

Alyssa Ross  writes:
>> > For example, why isn't ask-cert-level a default?
>>
>> For an alternative view on ask-cert-level see also:
>>
>> https://debian-administration.org/users/dkg/weblog/98
>
> Oh, interesting. Thank you for showing this to me. I had it in my head
> that a "weak" signature would count as a marginal in the web of trust,
> but I suppose I was wrong about that.
>
> In that case, I agree that ask-cert-level doesn't make sense as a
> default.

Well, that's also an ecosystem issue, and if I'm not mistaken this
thread (or was it another one?) was going quite far in the “let's fix
the ecosystem and keep the standard” direction.

“weak” *could* be used for verification. For instance, if I were to
write an OpenPGP client, I'd likely make it so that:
* Trust (which is 0-255 in the standard) is a slider with marks like “I
  trust not at all|a bit|a lot| completely” (with a proper sentence so
  that people understand, not like what I'm putting here)
* Signature level (4 levels in the standard) is a similar slider
* Both trust and signature level are mapped to a [0, 1] value, and
  multiplied to get the amount of confidence we have thanks to this
  particular signature that the key is correct
* All such amounts of confidence get added, and the “3-marginals or
  1-full” rule becomes a simple number that needs to be passed with this
  addition (also configured as a slider with some “normal user / … /
  paranoïd user” landmarks)

(for trust signatures, in such a scheme they'd first be cut off to
follow the OpenPGP certification, and then get multiplied by the length
of the path, to account for decreasing trust along longer paths)

This is compatible with RFC4880 (well, except it doesn't respect the
“SHOULD” that full trust is 120 and marginal 60, because it actually
uses the whole range).

So ask-cert-level might make sense as a default. Just not as GnuPG's
default, as GnuPG doesn't have such a behavior (and no client that I
know of currently do). But someday, maybe.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Your Thoughts

[Alyssa Ross]

> > For example, why isn't ask-cert-level a default?
>
> For an alternative view on ask-cert-level see also:
>
> https://debian-administration.org/users/dkg/weblog/98

Oh, interesting. Thank you for showing this to me. I had it in my head
that a "weak" signature would count as a marginal in the web of trust,
but I suppose I was wrong about that.

In that case, I agree that ask-cert-level doesn't make sense as a
default.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Your Thoughts

[Stefan Claas via Gnupg-users]

Alyssa Ross wrote:

Apologies for my late reply, I have overlooked your reply, sorry!

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

I would even say if --ask-cert-level would be a default it does
not guarantee how carefully a user has done key management. If you
look at WWW based key server interfaces you seldom see people who
have a policy link attached to their signature. And even if they would have
one, they differ from user to user, making to understand the WoT harder.

I tried to formulate such a policy a while ago, to strengthen the classical
(global) WoT a bit, but responses to my procedure were minimal.

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

Normally one needs only a few commands to use GnuPG successfully for
encryption and signing messages or encrypting files. Sure, when looking
at the GnuPG FAQ or the source code of GnuPG it is first to much
what someone has to study before he / she can use the software.

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS and GnuPG related issues and possible workarounds

[Peter Lebbing]

On 03/07/2019 18:37, Stefan Claas via Gnupg-users wrote:
> Why so upset?
> 
> I think I am allowed here to post my opinion and I do no "force"
> people.

You just said that if only you had the time and money, you would try to
take down the SKS network using a legal procedure. A procedure meant to
object to your data being available on the internet, while you clearly
don't have a problem with your data being available.

A year ago, you threatened to do precisely what has happened now: poison
Rob's OpenPGP key. You might even be the one that has done it, we can't
know.

That's not posting an opinion here. And it /is/ threatening to force
your way on other people.

This all is so bloody transparent that I don't see what your point is
yelling that the sky is green when clearly it's blue.

And apparently, I didn't check although it did ring a few bells, you
have in the past indicated you had wilfully fucked with other people's
OpenPGP keys to prove your point that it was possible. That's vandalism
in my book.

> EOD.

Neither of us gets to decide that for the other. BTW, you literally
asked a question ("Why so upset?").

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Werner Koch via Gnupg-users]

On Wed,  3 Jul 2019 17:08, stef...@sdaoden.eu said:

> I (still user of GPG1, it is only your newer key which this cannot

Just don't use it unless you need to decrypt very old mails.  In
particular not with keyservers or cards.  The next maintenance release
will anyway remove all keyserver and card code.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS and GnuPG related issues and possible workarounds

[Stefan Claas via Gnupg-users]

Peter Lebbing wrote:

> On 03/07/2019 17:33, Stefan Claas via Gnupg-users wrote:
> > Mmmhhh...Peter, if I should do this it should serve as help guideline
> > for users wishing to do the same.
> > 
> > Why?
> 
> Pfah. Stop rationalising. If this is your concern, create a website
> where your offer your services to people wishing to do this and
> advertise that website broadly. Then do it for the first person that
> truly wants to have their data removed.
> 
> I asked why you felt entitled to force your opinion upon others. You say
> nothing about that.
> 
> You just like to bully. That's your reason.
> 
> > Regarding my keybase presence, I can immediately close down my account
> > and my data and the data from my followers is removed, cool eh?
> 
> https://web.archive.org/web/20190423190205/https://keybase.io/stefan_claas
> 
> Yes, really cool! And totally beside the point, because I brought up
> keybase to illustrate my point that you do not want to invoke the GDPR
> currently to remove your data. If you would currently want to remove
> your data, you would have already closed your keybase account.
> 
> Peter.
> 

Why so upset?

I think I am allowed here to post my opinion and I do no "force" people.

If it's your impression I can live with it.

EOD.

Regards
Stefan


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS and GnuPG related issues and possible workarounds

[Peter Lebbing]

On 03/07/2019 17:33, Stefan Claas via Gnupg-users wrote:
> Mmmhhh...Peter, if I should do this it should serve as help guideline
> for users wishing to do the same.
> 
> Why?

Pfah. Stop rationalising. If this is your concern, create a website
where your offer your services to people wishing to do this and
advertise that website broadly. Then do it for the first person that
truly wants to have their data removed.

I asked why you felt entitled to force your opinion upon others. You say
nothing about that.

You just like to bully. That's your reason.

> Regarding my keybase presence, I can immediately close down my account
> and my data and the data from my followers is removed, cool eh?

https://web.archive.org/web/20190423190205/https://keybase.io/stefan_claas

Yes, really cool! And totally beside the point, because I brought up
keybase to illustrate my point that you do not want to invoke the GDPR
currently to remove your data. If you would currently want to remove
your data, you would have already closed your keybase account.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS and GnuPG related issues and possible workarounds

[Stefan Claas via Gnupg-users]

Stefan Claas via Gnupg-users wrote:

> Regarding my keybase presence, I can immediately close down my account
> and my data and the data from my followers is removed, cool eh?

One more thing... You uploaded your keys with friends signatures to
an SKS server and you are activists in one area. Because nowadays
everyone can run a key server and peer with others globally, you
*may* get later also a bit in trouble, if such a peering key server
is located in a country you visit for holidays, but this country may
not be as democratic as the country you live in and it may even
have a crypto usage ban.

The tool I currently use with friends can't bring me in possible
trouble that much, because it bears no data on my key from me and
the key ring with the keys from my friends has only nickname
entries (I can freely choose) for their keys.

My X.509 cert bears also no data from my friends.

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS and GnuPG related issues and possible workarounds

[Stefan Claas via Gnupg-users]

Peter Lebbing wrote:

> On 03/07/2019 16:00, Stefan Claas via Gnupg-users wrote:  
> > If I had time and money I would hire a lawyer, would formulate a letter
> > for SKS operators stating that I request the removal of my pub key data
> > and would as EU citizen refer in this letter to our GDPR.   
> 
> Do you object to your data being available not only from the many public
> archives of this mailing list but also from the SKS keyserver network?
> If so: why? Don't you think many more people would use a web search to
> find out about your name and e-mail address than use a keyserver search?
> And why the hell does  exist then?!?!
> 
> Or is it not that you wish to invoke the GDPR for what it was meant for,
> but rather you want to force the SKS keyserver network to go down,
> forcing your world view upon the good people running the network? If so:
> why do you feel entitled to do that?
> 
> I seem to remember you threatening, more than a year ago, to hose some
> specific person's public key, who was it again, with bogus third-party
> signatures.
> 
> I get the notion you're not what you'd call a "team player". "Bully"
> seems to be a better description. I'm going to leave it at that, because
> I don't want the list to go down the road I so desperately want to go
> personally. I'll take some solace from having recently read some
> stronger qualifications in a public post.
> 
> Peter.  

Mmmhhh...Peter, if I should do this it should serve as help guideline
for users wishing to do the same.

Why?

O.k. here is the deal: Let's say teenagers or younger people, like
you, made funny things with someone else's pub key and you get later
older and regret that someone has uploaded your pub key to the Network,
without your consent (of course...) then he / she should have the
possibility to remove that data, for what ever reason a person might
have.

Or say you are in the strong set, and later you figure out that a
person in the strong set is a criminal, you do not want any longer
associated with his / her signature on your key.

Then also don't forget that only GnuPG and one other tool has a WoT,
which even dgk could in one reply to me never explain what it is good
for. People may later change their careers and no longer, for what
ever reason they might have, do not want to be associated with the WoT.

I assume you only know crypto stuff as a GnuPG user and has never
used other crypto tools, otherwise you would not speak like this.

Regarding my keybase presence, I can immediately close down my account
and my data and the data from my followers is removed, cool eh?

Regards
Stefan


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Werner Koch via Gnupg-users]

On Wed,  3 Jul 2019 15:42, pe...@digitalbrains.com said:

> --keyserver-options self-sigs-only,import-minimal
>
> as I propose, why would it take longer than 0.2 s?

Indeed, we could change the code for import-minimal so that it first
does the same what self-sigs-only does.  Then it should be very similar.

The reason why I added self-sigs-only is to allow ignoring
key-signatures completely.  Regardless of any other cleaning options.
Sometimes it is useful to not clean things so that one can see hcnages
to preferences and such.

And well, self-sigs-only is a less intrusive change than changing
import-minimal.  If it breaks something it can easily be reverted by the
user - a change to the semantics of import-minimal can't be reverted by
the user.

"self-sigs-only" also better expresses what it does.  If you have a
better name, let us know.

> then the self-sigs-only behaviour can be folded into import-minimal,
> avoiding creating yet another option in an already crowded option space.

Removing the keyserver support would even result in more cleanup of that
space ;-)


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Steffen Nurpmeso]

Teemu Likonen wrote in <87zhlvta73@iki.fi>:
 |Steffen Nurpmeso [2019-07-03 17:08:32+02:00] wrote:
 |
 |> My question: is there any better way than a shell script over
 |> --list-keys --with-colon | grep ^pub | ...etc... to "minimize" keys in
 |> my keyring (with gpg1)?
 |
 |It seems that there is no better way than scripting it. My "--edit-key +
 |clean" script is below. It can be changed to "minimize".
 |
 |#!/bin/sh
 |gpg --batch --with-colons --list-keys | awk -F: '
 |$1 == "pub" {pub = 1}
 |pub == 1 && $1 == "fpr" {printf "%s clean save\n", $10; pub = 0}' | \
 | xargs -n3 -- gpg --batch --no-auto-check-trustdb --edit-key
 --End of <87zhlvta73@iki.fi>

Ah, thanks.  Cool!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Teemu Likonen via Gnupg-users]

Steffen Nurpmeso [2019-07-03 17:08:32+02:00] wrote:

> My question: is there any better way than a shell script over
> --list-keys --with-colon | grep ^pub | ...etc... to "minimize" keys in
> my keyring (with gpg1)?

It seems that there is no better way than scripting it. My "--edit-key +
clean" script is below. It can be changed to "minimize".


#!/bin/sh
gpg --batch --with-colons --list-keys | awk -F: '
$1 == "pub" {pub = 1}
pub == 1 && $1 == "fpr" {printf "%s clean save\n", $10; pub = 0}' | \
xargs -n3 -- gpg --batch --no-auto-check-trustdb --edit-key


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS and GnuPG related issues and possible workarounds

[Peter Lebbing]

On 03/07/2019 16:59, Stefan Claas via Gnupg-users wrote:
> Or do SKS key servers dictate how GnuPG's submission / receiving
> protocol must work?

It's in the reconsiliation protocol and the very foundation of the
assumptions of the synchronizing keyserver network. GnuPG doesn't come
anywhere near this protocol, it's just a downstream casualty of the
implications of the system.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Andrew Gallagher]

On 03/07/2019 16:13, Kristian Fiskerstrand wrote:
> potential DoS vector? (probably not the most efficient one, but...)

As in DoS amplification? I create a load of keys with a victim's URL in
the `keyserver` field and the pool does my dirty work? Interesting, but
so long as the keyservers' spiders are well behaved, it should be no
worse than being indexed by Google.

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS and GnuPG related issues and possible workarounds

[Andrew Gallagher]

On 03/07/2019 15:59, Stefan Claas via Gnupg-users wrote:
> Now, you awake my interest. You said it is the protocol, so let's
> say when Werner and his hackers has fixed the issue in GnuPG and
> for a protocol you usually have to sides, to work with, could that
> not mean then when Werner does x,y,z code in GnuPG that hockeypuck
> must follow x,y,z code in order that the protocol works ... ?!
> 
> Or do SKS key servers dictate how GnuPG's submission / receiving
> protocol must work?

There are several interlocking issues here. Firstly, gnupg locks up when
importing outsized keys. There are things that can be done at the import
stage, and this is what you mention above, but all of them just move
around the consequences of abuse. That's because of the second issue,
which is that the keyservers are abusable. You can fix this by making
keyservers verify the identity of the uploader (as hagrid and keybase
do), but this then makes the SKS reconciliation protocol unviable - so
it is SKS the protocol that has to be changed, not SKS the software.

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS and GnuPG related issues and possible workarounds

[Peter Lebbing]

On 03/07/2019 16:00, Stefan Claas via Gnupg-users wrote:
> If I had time and money I would hire a lawyer, would formulate a letter
> for SKS operators stating that I request the removal of my pub key data
> and would as EU citizen refer in this letter to our GDPR. 

Do you object to your data being available not only from the many public
archives of this mailing list but also from the SKS keyserver network?
If so: why? Don't you think many more people would use a web search to
find out about your name and e-mail address than use a keyserver search?
And why the hell does  exist then?!?!

Or is it not that you wish to invoke the GDPR for what it was meant for,
but rather you want to force the SKS keyserver network to go down,
forcing your world view upon the good people running the network? If so:
why do you feel entitled to do that?

I seem to remember you threatening, more than a year ago, to hose some
specific person's public key, who was it again, with bogus third-party
signatures.

I get the notion you're not what you'd call a "team player". "Bully"
seems to be a better description. I'm going to leave it at that, because
I don't want the list to go down the road I so desperately want to go
personally. I'll take some solace from having recently read some
stronger qualifications in a public post.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Kristian Fiskerstrand]

On 7/3/19 3:20 PM, Andrew Gallagher wrote:
> On 03/07/2019 13:45, Kristian Fiskerstrand wrote:
>> There are various ways this can be used for other
>> attack vectors as well, so they are mostly just ignored.
> 
> Any of those attack vectors applicable to keyservers attempting to
> refresh from it?
> 

potential DoS vector? (probably not the most efficient one, but...)

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Corruptissima re publica plurimæ leges
The greater the degeneration of the republic, the more of its laws



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Steffen Nurpmeso]

Werner Koch via Gnupg-users wrote in <87lfxfsiz0@wheatstone.g10code.de>:
 |On Tue,  2 Jul 2019 11:00, d...@fifthhorseman.net said:
  ...
 |import-clean does this:
 ...
 |[.]In contrast import-minimal
 |does this
 ...

I (still user of GPG1, it is only your newer key which this cannot
do for me) had

  export-options no-export-attributes,export-clean
  #import-options import-clean,merge-only
  import-options import-minimal,merge-only
  keyserver hkps://hkps.pool.sks-keyservers.net
  keyserver-options check-cert 
ca-cert-file=/home/steffen/sec.arena/pgp.git/sks-keyservers.net

in gpg.conf (also because the in-town TU Darmstadt key server is
of a terrible sort), but changed to import-minimal now, as above.
I note that after --refresh-keys all the signatures are still in
the DB, and even a truly updated key just loaded more signatures.
My question: is there any better way than a shell script over
--list-keys --with-colon | grep ^pub | ...etc... to "minimize"
keys in my keyring (with gpg1)?

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS and GnuPG related issues and possible workarounds

[Stefan Claas via Gnupg-users]

Stefan Claas via Gnupg-users wrote:

> O.k. but as understood it is in active development and I thought,
> even if it is the protocol, that it would be easier to fix issues
> in hockeypuck than in SKS, due to the fact that Golang is more
> modern and has a bigger programmers community.

Now, you awake my interest. You said it is the protocol, so let's
say when Werner and his hackers has fixed the issue in GnuPG and
for a protocol you usually have to sides, to work with, could that
not mean then when Werner does x,y,z code in GnuPG that hockeypuck
must follow x,y,z code in order that the protocol works ... ?!

Or do SKS key servers dictate how GnuPG's submission / receiving
protocol must work?

Regards
Stefan


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS and GnuPG related issues and possible workarounds

[Andrew Gallagher]

On 03/07/2019 15:41, Stefan Claas via Gnupg-users wrote:
> O.k. but as understood it is in active development and I thought,
> even if it is the protocol, that it would be easier to fix issues
> in hockeypuck than in SKS, due to the fact that Golang is more
> modern and has a bigger programmers community.

Sure, but it doesn't help server operators until after those changes are
made. And because hockeypuck is currently ineligible to be a member of
any of the pools, operators migrating en masse to it will hasten the
pools' death. If you don't have one of the poisoned keys in your
keyring, there's nothing wrong with continuing to use the keyservers
(for now), so we shouldn't kill a service that's working just fine for
those people, not until we have a replacement.

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

dirmngr not picking up new config?

[Peter Lebbing]

On 03/07/2019 15:06, Werner Koch wrote:
> Check that you do not have a keyserver entry in your gpg.conf or
> Enigmail is calling gpg with that options.  The keyserver specified by
> gpg overrides whatever dirmngr has been configured to.
> 
>   debug ipc
>   log-file /some/file
> 
> in dirmngr.conf should shows what is going on.

There hasn't been a keyserver line in my gpg.conf in a long time; I
checked this before I created dirmngr.conf. And I was testing on the
command line, using --refresh-keys.

My guess is: dirmngr reloads existing configuration files but fails to
check for new ones.

Here's a reproduction:

--8<---cut here---start->8---
$ pwd
/home/peter
$ rm .gnupg/dirmngr.conf 
$ gpgconf --kill all
$ gpg --refresh-keys ac46efe6de500b3e
gpg: refreshing 1 key from hkps://hkps.pool.sks-keyservers.net
gpg: key AC46EFE6DE500B3E: 2 signatures not checked due to missing keys
gpg: key AC46EFE6DE500B3E: "Peter Lebbing " not changed
gpg: Total number processed: 1
gpg:  unchanged: 1
$ cat >.gnupg/dirmngr.conf <" not changed
gpg: Total number processed: 1
gpg:  unchanged: 1
$ stat dirmngr.log
stat: cannot stat 'dirmngr.log': No such file or directory
$ gpgconf --kill dirmngr
$ gpg --refresh-keys ac46efe6de500b3e
gpg: refreshing 1 key from hkps://keys.openpgp.org/
gpg: key AC46EFE6DE500B3E: "Peter Lebbing " not changed
gpg: Total number processed: 1
gpg:  unchanged: 1
$ cat dirmngr.log
2019-07-03 16:30:01 dirmngr[13185.0] permanently loaded certificates: 0
2019-07-03 16:30:01 dirmngr[13185.0] runtime cached certificates: 0
2019-07-03 16:30:01 dirmngr[13185.6] handler for fd 6 started
2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 -> # Home: /home/peter/.gnupg
2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 -> # Config: 
/home/peter/.gnupg/dirmngr.conf
2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 -> OK Dirmngr 2.1.18 at your 
service
2019-07-03 16:30:01 dirmngr[13185.6] connection from process 13184 (1000:1000)
2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 <- GETINFO version
2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 -> D 2.1.18
2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 -> OK
2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 <- KEYSERVER
2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 -> S KEYSERVER 
hkps://keys.openpgp.org/
2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 -> OK
2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 <- KS_GET -- 
0x8FA94E79AD6AB56EE38CE5CBAC46EFE6DE500B3E
2019-07-03 16:30:01 dirmngr[13185.6] resolve_dns_addr for 'keys.openpgp.org': 
'keys.openpgp.org' [already known]
2019-07-03 16:30:01 dirmngr[13185.6] resolve_dns_addr for 'keys.openpgp.org': 
'keys.openpgp.org' [already known]
2019-07-03 16:30:01 dirmngr[13185.6] number of system provided CAs: 152
2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 -> S SOURCE 
https://keys.openpgp.org:443
2019-07-03 16:30:02 dirmngr[13185.6] DBG: (16329 bytes sent via D lines not 
shown)
2019-07-03 16:30:02 dirmngr[13185.6] DBG: chan_6 -> OK
2019-07-03 16:30:02 dirmngr[13185.6] DBG: chan_6 <- BYE
2019-07-03 16:30:02 dirmngr[13185.6] DBG: chan_6 -> OK closing connection
2019-07-03 16:30:02 dirmngr[13185.6] handler for fd 6 terminated
--8<---cut here---end--->8---

Here's the stuff my Debian stable reports about my GnuPG:

--8<---cut here---start->8---
Package: gnupg
Version: 2.1.18-8~deb9u4

-- System Information:
Debian Release: 9.9
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable'), (610, 'testing'), (600, 
'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 5.0.15 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnupg depends on:
ii  gnupg-agent2.1.18-8~deb9u4
ii  libassuan0 2.4.3-2
ii  libbz2-1.0 1.0.6-8.1
ii  libc6  2.24-11+deb9u4
ii  libgcrypt201.7.6-2+deb9u3
ii  libgpg-error0  1.26-2
ii  libksba8   1.3.5-2
ii  libreadline7   7.0-3
ii  libsqlite3-0   3.16.2-5+deb9u1
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages gnupg recommends:
ii  dirmngr 2.1.18-8~deb9u4
ii  gnupg-l10n  2.1.18-8~deb9u4

Versions of packages gnupg suggests:
pn  parcimonie  
pn  xloadimage  

-- no debconf information
--8<---cut here---end--->8---

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS and GnuPG related issues and possible workarounds

[Stefan Claas via Gnupg-users]

Andrew Gallagher wrote:

> On 03/07/2019 15:27, Stefan Claas via Gnupg-users wrote:
> > Sure, of course. Meanwhile SKS operators may check out hockeypuck (written
> > in Golang :-)), if that helps.
> 
> It's the protocol that's broken, not the software. Migrating from SKS to
> hockeypuck doesn't (in itself) fix the problems.

O.k. but as understood it is in active development and I thought,
even if it is the protocol, that it would be easier to fix issues
in hockeypuck than in SKS, due to the fact that Golang is more
modern and has a bigger programmers community.

Regards
Stefan 


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS and GnuPG related issues and possible workarounds

[Andrew Gallagher]

On 03/07/2019 15:27, Stefan Claas via Gnupg-users wrote:
> Sure, of course. Meanwhile SKS operators may check out hockeypuck (written
> in Golang :-)), if that helps.

It's the protocol that's broken, not the software. Migrating from SKS to
hockeypuck doesn't (in itself) fix the problems.

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS and GnuPG related issues and possible workarounds

[Stefan Claas via Gnupg-users]

Andrew Gallagher wrote:

> On 03/07/2019 15:00, Stefan Claas via Gnupg-users wrote:
> > If I had time and money I would hire a lawyer, would formulate a letter
> > for SKS operators stating that I request the removal of my pub key data
> > and would as EU citizen refer in this letter to our GDPR. 
> > 
> > Maybe, if time allows, I may check with EFF and their lawyers ...
> 
> Would you mind waiting for the replacement system to be fully tested and
> migrated before setting fire to the old one?

Sure, of course. Meanwhile SKS operators may check out hockeypuck (written
in Golang :-)), if that helps.

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Kristian Fiskerstrand]

On 7/3/19 10:17 AM, Andrew Gallagher wrote:
> On 03/07/2019 05:46, Phil Pennock via Gnupg-users wrote:
>> Beware: the HKP schema of paths is used with the keyserver in that
>> field, in GnuPG at least.
> OK, but what's the failure mode? If it's graceful, then we haven't lost
> much. So long as key updates fall back to a keyserver somewhere it
> should be transparent.
> 
> This does of course need thorough testing, as not all clients will have
> the same failure modes.
> 

at least one issue that has been pointed out historically about relying
on specification of TPK URI for refresh is privacy issues related to
callbacks and/or DoS. There are various ways this can be used for other
attack vectors as well, so they are mostly just ignored.

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Corruptissima re publica plurimæ leges
The greater the degeneration of the republic, the more of its laws



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS and GnuPG related issues and possible workarounds

[Andrew Gallagher]

On 03/07/2019 15:00, Stefan Claas via Gnupg-users wrote:
> If I had time and money I would hire a lawyer, would formulate a letter
> for SKS operators stating that I request the removal of my pub key data
> and would as EU citizen refer in this letter to our GDPR. 
> 
> Maybe, if time allows, I may check with EFF and their lawyers ...

Would you mind waiting for the replacement system to be fully tested and
migrated before setting fire to the old one?

There's a scene in the classic comedy Father Ted, where a visitor to the
parochial house starts complaining about the build quality of the
bookshelves, and to prove his point he pulls them to pieces. "Look at
that, it's falling apart!" [1]

Just because something is broken does not mean you are obliged to kick
it over to prove the point.

[1] https://vimeo.com/108169770

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Your Thoughts

[Ryan McGinnis via Gnupg-users]

Not sure why the phone number thing bothers people -- having a phone at all in 
the first place means you are easily tracked.  What Signal (and any encryption 
system, really) does is try to prevent in-transit interception and surveillance 
of the actual data content.  It can't hide the metadata associated with a layer 
well above the application layer.  Openwhisper can be picked up at the firewall 
level, but then so can Tor and VPN spinups, and all of these things are 
metadata that make you score more interesting to the mass-data-scoop 
algorithms.  If you don't want to be easily geo-locationally tracked, don't use 
a device with a cellular modem, full stop.  


What Signal (or any other E2E encrypted messaging system) does is give people 
the ability to communicate with each other privately.  People can still see 
that they are talking and are trying to hide what they are saying.  Yeah, that 
makes those people targets in some countries, but it also greatly increases the 
cost in manpower and resources needed to peek into those communications.  Now 
you're looking at burning 0days to install APTs and sending human resources to 
deal with individuals when this could previously be handled on a global level 
en masse with some fiber splitters and a big ol' datacenter.  If enough people 
use it can have a disruptive effect on mass surveillance and state control.  



-Ryan McGinnis
https://bigstormpicture.com
PGP: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD
Sent with ProtonMail

‐‐‐ Original Message ‐‐‐
On Tuesday, July 2, 2019 10:20 PM, Mirimir via Gnupg-users 
 wrote:

> On 07/02/2019 05:18 AM, Robert J. Hansen wrote:
> 

> > > Signal went the other way. Build a verifiably secure communications 
> > > platform so easy that literally anyone can figure it out.
> > 

> > I think this is a misunderstanding of Signal.
> 

> 
> 

> > Signal is, by its very nature, tightly tied to one specific
> > communications platform -- that of the smartphone. It's not likely to
> > break out of its home.
> 

> And not only that, it's tied to one of the least privacy-friendly
> aspects of smartphones: the phone number.[0]
> 

> | Requirements
> |
> | Signal uses your existing phone number.
> |
> | The number must be able to receive an SMS or phone call.
> 

> Sure, it's not necessarily the number of the phone that you're using
> Signal on. But it's gotta be a number that you can use, and which others
> can't use. So what do you do, to avoid geolocation?
> 

> You can't use one of those shared SMS services. So what, lease a SIM
> from some SIM farm in wherever, and hope that they're honest?
> 

> There's also the issue of actually using Signal while preventing
> geolocation. You can't just use Tor, which itself is nontrivial on
> smartphones, because Signal needs UDP. So you're stuck with VPNs, where
> you must trust providers.
> 

> It's frightening how popular Signal has become. Especially for people
> whose lives are threatened by geolocation. If I were paranoid, I'd say
> that it was a honeypot. But whatever. Something using Tor onion services
> is probably the best option. Unless Tor is also a honeypot.
> 

> 
> 

> 0)
> https://support.signal.org/hc/en-us/articles/360007318691-Register-a-phone-number
> 

> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users



publickey - ryan@digicana.com - 0x5C738727.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Local solutions: SKS Keyserver Network Under Attack

[Peter Lebbing]

Hello Roland,

On 03/07/2019 15:00, Roland wrote:
> And for Enigmail: your suggestion or In the terminal, to edit
> ~/.gnupg/dirmngr.conf so as to say "keyserver
> hkps://keys.openpgp.org/" or, if that file does not exist to create it
> as per your suggestion.

I don't think Enigmail respects dirmngr.conf, it just provides its own
set of keyservers. At least, if I delete them all from the Preferences
dialog of Enigmail, it prompts me to enter a keyserver, defaulting to
the literal text "undefined".

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS and GnuPG related issues and possible workarounds

[Stefan Claas via Gnupg-users]

Vincent Breitmoser via Gnupg-users wrote:

> 
> Friendly reminder: There are no developers working on SKS right now. Zero. No
> actual work has been done on SKS in years.
> 
>  - V

Correct. If I would be an SKS operator I would switch to your Hadgrid,
to support the PGP / GnuPG community.

If I had time and money I would hire a lawyer, would formulate a letter
for SKS operators stating that I request the removal of my pub key data
and would as EU citizen refer in this letter to our GDPR. 

Maybe, if time allows, I may check with EFF and their lawyers ...

Regards
Stefan


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Peter Lebbing]

Hi,

On 03/07/2019 15:10, Werner Koch wrote:
> Yes, as I wrote: 0.2s compared to 50s.

I fear we're miscommunicating, so let me try to rephrase it again. Sorry
for my persistence, it's only because I think we're miscommunicating and
it would be good if that could be fixed.

If

--keyserver-options import-minimal

behaved like

--keyserver-options self-sigs-only,import-minimal

as I propose, why would it take longer than 0.2 s?

If there is no good use case for using

--keyserver-options self-sigs-only

instead of

--keyserver-options self-sigs-only,import-minimal

or for using

--keyserver-options import-minimal

instead of

--keyserver-options self-sigs-only,import-minimal

then the self-sigs-only behaviour can be folded into import-minimal,
avoiding creating yet another option in an already crowded option space.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re:

[Andrew Gallagher]

On 03/07/2019 14:00, Roland wrote:

> 1/ Perhaps the fear of compromised communication (including
> distributed software, private messages) can be mitigated by
> practicing short feed back lines: confirmations. Like "did you get my
> communication, what did it say?"

If your communication pathway is untrustworthy, it is more effective to
use multiple independent lines of communication than multiple messages
over the same channel. This is still not foolproof, but it significantly
increases the difficulties faced by an attacker. That said, if you've
already leaked your secrets over the insecure channel it may be too late
for you.

> 2/ Perhaps one should not give too much trust to a WoT at all. After
> all, a crook can pretend to be a friend, and thus yield the entire
> WoT untrustworthy

This is not quite true - if I am the recipient of a message, I must
explicitly assign "signing trust" to all the links in the signature
chain, in addition to assigning "identity verification" to the root of
that chain. I can also assign "marginal trust" so that more than one
verification pathway is required, to protect against duplicitous
individuals.

But you're right, these subtleties are why WoT never took off. :-)

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Andrew Gallagher]

On 03/07/2019 13:45, Kristian Fiskerstrand wrote:
> There are various ways this can be used for other
> attack vectors as well, so they are mostly just ignored.

Any of those attack vectors applicable to keyservers attempting to
refresh from it?

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Werner Koch via Gnupg-users]

On Wed,  3 Jul 2019 13:50, pe...@digitalbrains.com said:

> Is there a good use-case for the former? If the latter also filtered out

Yes, as I wrote: 0.2s compared to 50s.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Local solutions: SKS Keyserver Network Under Attack

[Werner Koch via Gnupg-users]

On Wed,  3 Jul 2019 12:58, pe...@digitalbrains.com said:

> reached its intended goal: dirmngr said "re-reading config". It just
> didn't have an effect for some odd reason. For people thinking about

Check that you do not have a keyserver entry in your gpg.conf or
Enigmail is calling gpg with that options.  The keyserver specified by
gpg overrides whatever dirmngr has been configured to.

  debug ipc
  log-file /some/file

in dirmngr.conf should shows what is going on.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS and GnuPG related issues and possible workarounds

[Michał Górny via Gnupg-users]

On Wed, 2019-07-03 at 03:01 -0700, Mirimir via Gnupg-users wrote:
> On 07/02/2019 11:42 PM, Michał Górny wrote:
> > Then, they may decide to start mass poisoning other keys just to 
> > prove this is not the right solution.
> 
> If what I propose is workable, attackers can poison as many keys as they
> like. Until SKS keyservers go down, anyway. Until then, if the system
> catches them quickly enough, they won't do widespread damage. They'll
> inconvenience some people, of course, but that seems unavoidable. And as
> an extra benefit, this would nuke file systems that store data in
> signatures.
> 

I'm afraid you are underestimating those people.  The way I see it,
the number of poisoned OpenPGP keys will grow quick enough to remove all
valid keys from SKS keyservers, and render them practically useless.


-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Local solutions: SKS Keyserver Network Under Attack

[Roland]

Thanks, Peter, for this confirmation.

You give further detail to what I had guessed in the course of playing 
with the settings of GPA and Kleopatra.


I conclude that there are at least two possible actions for those who 
want to protect there systems:
In the GUIs of GPA or Kleopatra to fiddle the settings as I suggested 
earlier in this thread. And for Enigmail: your suggestion

or
In the terminal, to edit ~/.gnupg/dirmngr.conf so as to say "keyserver 
hkps://keys.openpgp.org/" or, if that file does not exist to create it 
as per your suggestion.


This could be useful for some mere common GnuPG users, like me.

Greetz

Roland

Some side thoughts:
1/ Perhaps the fear of compromised communication (including distributed 
software, private messages) can be mitigated by practicing short feed 
back lines: confirmations. Like "did you get my communication, what did 
it say?"
2/ Perhaps one should not give too much trust to a WoT at all. After 
all, a crook can pretend to be a friend, and thus yield the entire WoT 
untrustworthy. Sometimes a friend becomes an enemy at a later stage. As 
a very ordinary mere user, I do not really understand the trust levels 
that GnuPG asks me to consider. How can a WoT that is not 100% 
understood by absolutely all users be reliable?
3/ With these thoughts, I hope NOT to embarrass the developers. Forget 
it, if you consider it useless for your troubles. (Thanks for GnuPG!)



On 03/07/2019 12:58, Peter Lebbing wrote:

Hello Roland,


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.

The usual case on Linux systems is that if a configuration file would
otherwise be empty or equal to the default (the two can be entirely
different things in general!), the configuration file simply does not
exist.

So instead of modifying ~/.gnupg/dirmngr.conf, *create* one and put a
single line in it saying

keyserver hkps://keys.openpgp.org/

I encountered some strange behaviour here: I invoked

$ gpgconf --reload dirmngr

afterwards (otherwise dirmngr will not reconsider its now changed
configuration), and it *did not work*. It was still using the default.
It did work after I rebooted (I was not in the mood to fiddle more with
it and did the most heavy-handed thing that would work).

Also, Enigmail doesn't seem to use this configuration at all and instead
it is configured at

Enigmail -> Preferences -> Keyserver

I did verify using systemd's journal that the gpgconf --reload command
reached its intended goal: dirmngr said "re-reading config". It just
didn't have an effect for some odd reason. For people thinking about
this: no, I don't use Tor for keyservers, it's not related to dirmngr
refusing to change keyservers when on Tor.

HTH,

Peter.




___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Peter Lebbing]

Hello,

On 03/07/2019 13:17, Werner Koch wrote:
> --keyserver-options recognizes all import options in addition to
> keyserver specific options.

But then import-minimal could be modified so it includes the behaviour
currently planned for self-sigs-only, and import-minimal could be made
the default for --keyserver-options, eliminating the need for another
option called self-sigs-only.

I don't think there is a need for the extra granularity:

1) --keyserver-options self-sigs-only retains all self-sigs

2) --keyserver-options import-minimal retains only the most recent
   self-sig

Is there a good use-case for the former? If the latter also filtered out
non-self-sigs in a very early stage like planned for self-sigs-only, in
addition to its current functionality in a later stage of import, it
would prevent the poison.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Werner Koch via Gnupg-users]

On Wed,  3 Jul 2019 12:29, pe...@digitalbrains.com said:

> Ah, based on a new message I just read the penny dropped. self-sigs-only
> can be made a default because it only applies to keyservers.
> import-minimal cannot be made a default because it affects all other

Not quite.  When importing from a keyserver you use --keyserver-options
and thus this allows to have a different set of options than when
importing using --import (and its corresponding --import-options
option).  --keyserver-options recognizes all import options in addition
to keyserver specific options.

The main advantage of self-sigs-only is that it is really fast.
Importing dkg's keys from a file takes 0.2s.  Importing without that
option takes 50 seconds.  The latter takes a long time until it runs
into the size limit which then triggers the fallback to self-sigs-only.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Teemu Likonen via Gnupg-users]

Werner Koch [2019-07-03 12:04:55+02:00] wrote:

> On Wed,  3 Jul 2019 10:38, tliko...@iki.fi said:
>> I think everyone would prefer that import-clean would do all the
>> checking and cleaning before importing certificates to the local
>> keyring. The same thing with import-minimal.
>
> It does this. However for 150k signatures it even takes quite some
> time to check whether the key does not exist locally so that the
> signature won't be imported.

Good. So in principle it works well. Thanks you.

I downloaded (--receive-key) a poisoned key into an empty keyring using
two different keyserver-options. The duration was practically the same.

import-clean:   1 min 28 s
import-minimal: 1 min 25 s

I would expect import-minimal be much faster or actually both quite fast
as my test keyring was empty on both tries. Anyway, it works and those
options seem to protect keyring from getting poisonous certificates.
There is the DOS aspect of course as it takes quite long.

The same --receive-key without any keyserver-options hits gpg's limits
at 26 seconds:

gpg: key [...]: 4 duplicate signatures removed
gpg: key [...]: 54614 signatures not checked due to missing keys
gpg: key [...]: 4 signatures reordered
gpg: error writing keyring '[...]/pubring.kbx': Provided object is too large
gpg: key [...]: public key "[User ID not found]" imported
gpg: Total number processed: 1
gpg:   imported: 1
gpg:   not imported: 1


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Local solutions: SKS Keyserver Network Under Attack

[Peter Lebbing]

Hello Roland,

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

The usual case on Linux systems is that if a configuration file would
otherwise be empty or equal to the default (the two can be entirely
different things in general!), the configuration file simply does not
exist.

So instead of modifying ~/.gnupg/dirmngr.conf, *create* one and put a
single line in it saying

keyserver hkps://keys.openpgp.org/

I encountered some strange behaviour here: I invoked

$ gpgconf --reload dirmngr

afterwards (otherwise dirmngr will not reconsider its now changed
configuration), and it *did not work*. It was still using the default.
It did work after I rebooted (I was not in the mood to fiddle more with
it and did the most heavy-handed thing that would work).

Also, Enigmail doesn't seem to use this configuration at all and instead
it is configured at

Enigmail -> Preferences -> Keyserver

I did verify using systemd's journal that the gpgconf --reload command
reached its intended goal: dirmngr said "re-reading config". It just
didn't have an effect for some odd reason. For people thinking about
this: no, I don't use Tor for keyservers, it's not related to dirmngr
refusing to change keyservers when on Tor.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Peter Lebbing]

On 03/07/2019 11:59, Peter Lebbing wrote:
> What is the difference in the end result between --keyserver-options
> self-sigs-only and --import-options import-minimal?

Ah, based on a new message I just read the penny dropped. self-sigs-only
can be made a default because it only applies to keyservers.
import-minimal cannot be made a default because it affects all other
methods of importing.

Hope that helps myself / Happy to help myself / HTHM,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Werner Koch via Gnupg-users]

On Wed,  3 Jul 2019 10:38, tliko...@iki.fi said:

>> import-clean does this:
>>
>>After import, compact (remove all signatures except the
>>self-signature)
>
> ...here you and the manual say that "first import [to local keyring]
> then clean".
>
> So there are conflicting messages. Which of the two happens?

Right, the man page is a ambigious in use of the term "import".  It
should say that "after the key has been received by gpg, is is compacted
..., and if no error is encountred written to the keyring".

> I think everyone would prefer that import-clean would do all the
> checking and cleaning before importing certificates to the local
> keyring. The same thing with import-minimal.

It does this.  However for 150k signatures it even takes quite some time
to check whether the key does not exist locally so that the signature
won't be imported.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS and GnuPG related issues and possible workarounds

[Wiktor Kwapisiewicz via Gnupg-users]

On 03.07.2019 11:06, Robert J. Hansen wrote:

Those two account for literally 99% of all use cases.  The vast majority
of OpenPGP is to verify package signatures; for the small fraction that
use it for email, Enigmail is the most dominant choice, with GpgOL a
close second.


Yes. It seems distros that I know of manually manage package signing 
keys so they wouldn't be vulnerable to this kind of attack:


https://blog.liw.fi/posts/2019/07/02/debian_and_the_sks_signature_flooding_attack/

(although it would be a chore as previously they could just --refresh-keys).

For something completely different: on gnupg-devel there was a 
discussion on using Web Key Directory first for fetching signing keys.


So "gpg --auto-key-retrieve --verify HOWTO.txt.sig HOWTO.txt" would get 
the key from sixdemonbag.org instead of keyservers thus retrieving good, 
non-flooded key. The change is tracked at https://dev.gnupg.org/T4595


Kind regards,
Wiktor

--
https://metacode.biz/@wiktor

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

SKS and GnuPG related issues and possible workarounds

[Mirimir via Gnupg-users]

On 07/02/2019 11:42 PM, Michał Górny wrote:
> Dnia July 3, 2019 6:23:37 AM UTC, Mirimir via Gnupg-users 
>  napisał(a):



>> I don't think that it's necessary to stop using SKS keyservers. And I
>> suspect that doing so would be nontrivial. Given that requests to them
>> are likely hard-coded, or buried in obscure options and preferences.
>> Stuff that nobody has touched for years.
>>
>> I believe that the most practical approach is 1) efficiently finding
>> toxic keys, and 2) reconfiguring keyservers not to serve them. I get
>> that many find this distasteful, doing the attackers' work for them,
>> etc, etc, etc. But it would limit damage, to the extent that toxic keys
>> can be identified soon enough. And there are other ways to share good
>> copies of those keys. Via Keybase, for example. Or as you say,
>> manually.
> 
> I don't think this is going to work long term. Even if you manage to 
> somehow synchronously control all servers in SKS rotation, there's no 
> way to prevent attackers from poisoning them over and over again.

I'm not suggesting any controls on a server-by-server basis. I'm
suggesting that blacklisting of toxic keys be a software update. And as
the Tor network does, keyservers would ignore peers running outdated
versions.

Also, if what I propose is workable, toxic keys won't matter. They'll
just be wasted space on the keyservers. And indeed, "poisoning them over
and over again" isn't at all an issue. Given that toxic keys, or the
signatures that poison them, can't actually be removed. By design, to
prevent censorship.

> Then, they may decide to start mass poisoning other keys just to 
> prove this is not the right solution.

If what I propose is workable, attackers can poison as many keys as they
like. Until SKS keyservers go down, anyway. Until then, if the system
catches them quickly enough, they won't do widespread damage. They'll
inconvenience some people, of course, but that seems unavoidable. And as
an extra benefit, this would nuke file systems that store data in
signatures.



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS and GnuPG related issues and possible workarounds

[Werner Koch via Gnupg-users]

On Wed,  3 Jul 2019 05:06, r...@sixdemonbag.org said:

> As I understand it the current list of targeted keys is myself, dkg,
> Werner, Patrick, and Kristian.  It is clear the attacker's goal is to

I am not yet affected except for these few thousand old xmas fun
signatures.

> Werner will no doubt be updating GpgOL as well.

I am sorting out some other bugs and hope to get a release out next
week.  I tend to make

  --keyserver-options self-sigs-only

the default to avoid importing possible crap from the keyservers.
no-self-sigs-only should allow to revert for those who still want to
receive updates from the anyway overloaded keyservers.  A command to
clean affected keys would also be useful but it might be better to get a
new release out early than to implement a feature which needs quite some
time taking testing. (https://dev/gnupg.org/T4591)

What we can also do is to remove the default keyserver feature we
introduced with 2.2.  This means that anyone who wants to use a
keyserver needs to pick one and not rely on defaults.

The other thing I have in mind to actually add to 2.2 is to re-purpose
--search-keys to update from WKD or DANE instead looking up at the
keyservers. (T4599)


> of OpenPGP is to verify package signatures; for the small fraction that
> use it for email, Enigmail is the most dominant choice, with GpgOL a

Frankly, I doubt that given the many users of Gpg4win compared to those
of Linux desktops.  But this is a different topic.

> The real damage is going to be to people's workflows.  A whole lot of
> people are going to be impacted by these fixes and we can expect to need

Actually not being able to fetch a key from the keyservers can improve
security or at least avoid problems sending mails encrypted to the wrong
key.  (see my comment above on --search-keys).


Shalom-Salam,

   Werner


p.s.
Why can't we have such problems at times when it is cold and rainy and
you can anyway only sit at your desk ;-).

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Peter Lebbing]

On 03/07/2019 09:13, Werner Koch via Gnupg-users wrote:
> The current state is that we keep only self-signatures and then then
> import again with import-clean (which is then basically identical to
> import-minimal).

What is the difference in the end result between --keyserver-options
self-sigs-only and --import-options import-minimal? I think the former
keeps all self sigs and the latter only the most recent valid self sig?
Is it perhaps possible to incorporate the desired functionality of
self-sigs-only into import-minimal, avoiding another extra option?
Perhaps the extra granularity of self-sigs-only is not a useful feature
for users, and poisoned keys should just be imported by import-minimal
which could automatically imply the current functionality of
self-sigs-only.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS and GnuPG related issues and possible workarounds

[Vincent Breitmoser via Gnupg-users]

Friendly reminder: There are no developers working on SKS right now. Zero. No
actual work has been done on SKS in years.

 - V


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS and GnuPG related issues and possible workarounds

[Robert J. Hansen]

> a. The entire SKS keyservers design and interaction has a fundamental
> design flaw named "unlimited resources assumption". I.e., it is assumed
> every server, every client has unlimited resources (to store signatures;
> to retrieve and process them - unlimited RAM/storage, unlimited network
> speed).

This is reasonably correct.  You'll get well-intentioned pedants
screaming at you that you've got things exactly wrong (as I have
discovered in recent days), but ignore them.

> b. It is only a matter of time when other certificates are under attack.

As I understand it the current list of targeted keys is myself, dkg,
Werner, Patrick, and Kristian.  It is clear the attacker's goal is to
wedge as many GnuPG installations as possible.

> When the ones used by, say, Linux distributions to sign packages are
> affected, that will cause another wave of chaos.

Yes.  A warning is in order: few distributions use the keyserver network
to distribute signing certificates directly.  However, given the
behavior of --refresh-keys, one could always upload a poisoned signing
certificate to the keyserver network, wait for sysadmins to do a
--refresh-keys on the entire keyring, and blammo.

> So the only valid
> option is to stop using current (the one written in OCaml) keyserver
> implementation and return to stone-age practice of manually sending them.

Or switch to Autocrypt, WKD, or Hagrid.  All three options are worth
considering, although none of them are (or could be) drop-in replacements.

> c. More or less valid approach would be to
> - when exchanging with keyserver, only load/transmit signatures for
> certificates in the user's keyring. To withstand traffic and other
> resources waste, client should pass known certificates footprints first,
> to only get from a keyserver the relevant signature
> - implement local black/white lists feature - to able to filter out the
> signatures while processing them

This would only shift the problem, not cure it.  Once you poison a
certificate until it's a few gigabytes in size, you can easily kill the
entire SKS network by forcing it to reconcile that certificate over and
over.

> Am I wrong - perhaps there are brighter alternatives?

I am *cautiously* optimistic.

As an emergency mitigation, I think distributions should consider
issuing a system update that blackholes *.sks-keyservers.net, with a big
warning to people about what's happening and why.

Enigmail users are, at present, getting hit left and right due to (a)
how many of them have an affected certificate in their keyrings and (b)
Enigmail's habit of automatically refreshing keyrings.  Patrick has
already sent an emergency message to the Enigmail mailing list, and an
emergency update will be released imminently shifting to keys.openpgp.net.

Werner will no doubt be updating GpgOL as well.

Those two account for literally 99% of all use cases.  The vast majority
of OpenPGP is to verify package signatures; for the small fraction that
use it for email, Enigmail is the most dominant choice, with GpgOL a
close second.

The one small bit of silver lining to this stormcloud is we only need to
figure out how to fix three separate things.

The real damage is going to be to people's workflows.  A whole lot of
people are going to be impacted by these fixes and we can expect to need
to help an awful lot of them.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: New keyserver at keys.openpgp.org - what's your take?

[Andrew Gallagher]

On 03/07/2019 05:46, Phil Pennock via Gnupg-users wrote:
> Beware: the HKP schema of paths is used with the keyserver in that
> field, in GnuPG at least.

OK, but what's the failure mode? If it's graceful, then we haven't lost
much. So long as key updates fall back to a keyserver somewhere it
should be transparent.

This does of course need thorough testing, as not all clients will have
the same failure modes.

> Using http:/https: didn't help, HKP was still used.

Yes, from my reading this is expected behaviour. It would be relatively
straightforward to create a server-side alias for the HKP URL, depending
on what else is deployed at that location.

> I got around it later by specifying a `finger:` URL.  :)
> It's been 30-40 years since folks last revamped the conventions on top
> of finger.  That one is safe.

I didn't even know it supported finger URLs - handy to know! Opening a
finger port may be a step too far for the security-conscious though...

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Teemu Likonen via Gnupg-users]

Werner Koch via Gnupg-users [2019-07-03 08:57:55+02:00] wrote:

> On Tue,  2 Jul 2019 11:00, d...@fifthhorseman.net said:
>> But "clean-then-import" is clearly a preferable approach to any of the
>> workarounds described so far.
>
> --import-options import-clean does exactly this.

Daniel basically said that "first clean then import [to local keyring]"
and you confirmed that import-clean does exactly this.

But then...

> import-clean does this:
>
>After import, compact (remove all signatures except the
>self-signature)

...here you and the manual say that "first import [to local keyring]
then clean".

So there are conflicting messages. Which of the two happens?

I think everyone would prefer that import-clean would do all the
checking and cleaning before importing certificates to the local
keyring. The same thing with import-minimal.

-- 
/// Teemu Likonen    //
// PGP: 4E1055DC84E9DFF613D78557719D69D324539450 ///


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: distributing pubkeys: autocrypt, hagrid, WKD

[Werner Koch via Gnupg-users]

On Tue,  2 Jul 2019 15:40, konstan...@linuxfoundation.org said:

> When this happens, a maintainer who tries to verify a signed pull
> request will have the operation fail, so they need to have a way to
> force-refresh the developer's key. I would say this is the #1 workflow

Agreed.  A signature carries only the fingerprint of the then unknown
subkey without any information on the primary key.  Thus an automated
lookup is not possible.

But wait, if --sender has been used or due to other reasons the Signer's
UID is included in the keyring, we could do a lookup via tha user-id to
see whether the signature has been made by a new subkey.  The
--auto-key-retrieve code already respective code but we need to chnage
the order from where a key is fetched.

And yes, an easier to remember command to forcefully update a key would
be very useful.   I have

  gpg --serach-key MAILADDRESS

for that in mind.  See https://dev/gnupg.org/T4599


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Werner Koch via Gnupg-users]

On Wed,  3 Jul 2019 12:35, gnupg-users@gnupg.org said:

> problem but I have read RJH's article). It sounds like SKS servers can
> handle these poisoned keys but GPG can't. That suggests that maybe GPG's

I think here is a misunderstanding.  Sure, processing 150k signatures
takes quite some time and makes things very slow.  This is why we call
it a DoS.  We can't do much about it.  Compare it to X.509 CRLs - they
have a very similar problem (cacert.org is a prominent but not the only
example of CRLs making S/MIME processing very slow).

The actual problem in gpg when using the keybox format is that only
after processing the imported keys we hit a 5MiB limit for the keyblock
in the database layer.  Thus the import fails.  Determining the size of
the keyblock as it will be stored requires that we first remove some
(standard) garbage from the keyblock - this takes some time.  With the
currently deployed code gpg will just reject any updates from a key if
that limit was reached.  That is not a good choice and the reason why I
call it a bug.   The fix to this bug is to fallback importing a stripped
down version of the key.  The current state is that we keep only
self-signatures and then then import again with import-clean (which is
then basically identical to import-minimal).

> For example, if the problem is overuse of resources such as memory, could
> the keyring handling code be rewritten to use fewer resources? e.g. treat

Years ago we had the problem that people uploaded keys with large user
ids and such.  Thus we introduced limits to avoid spamming the keyring
with such faked data.  There is also an overall limit of 5 MiB for the
entire keyblock which is sufficient for all real-world keyblocks - even
for those with many key-signatures.

> signatures when importing a key, perhaps there could be a limit to how many
> signatures GPG will verify. Does it really have to verify every single one?

It needs to validate all self-signature because they make up the
integrity of the keyblock.  For key-signature, sure we could introduce a
limit, we actually do that with import-clean because that imports only
those key-signature which we can verify and which are the latest from the
same key (it is possible to sign a key several times to change meta data
associated with the key-signature).


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Werner Koch via Gnupg-users]

On Tue,  2 Jul 2019 11:00, d...@fifthhorseman.net said:

> It sounds like you are saying that the order of operations --
> import-then-clean vs. clean-then-import is part of the API spec that
> GnuPG is committed to.

No.  What I say is that if we want to clean the keys from bogus
signatures we need to get the key for each signature first.  Obviously
this requires that we do some checking on that key as a weel and this is
why I say it is a catch-22.

However, if you are only talking about self-signature, there is for sure
no problem: We already have the key (it is a self-signature) and thus we
can immediately check the signature.  Anyway, that takes some time, it
is a crypto operation - multiply that by 15.  OTOH, simply removing
non-self-signatures does not costs any measurable time because it is
just comparing two integers.

> But "clean-then-import" is clearly a preferable approach to any of the
> workarounds described so far.

--import-options import-clean does exactly this.  With the latest pacth
we fallback to this option and --self-sigs-only if gpg detects that the
keyblock is too larger afer some basic checks.

> certificate in the keyring.  "clean" means that the certificates already
> stored in the keyring are used to validate incoming signatures.  right?

import-clean does this:

   After import, compact (remove all signatures except the
   self-signature) any user IDs from the new key that are not usable.
   Then, remove any signatures from the new key that are not usable.
   This includes *signatures that were issued by keys that are not*
   *present on the keyring*. This option is the same as running the
   --edit-key command "clean" after import. Defaults to no.

This import-clean works on all signatures, not just self-signatures.
This is what takes time - finding the key in the keyring (slower since
2.1 due to DB correctness improvements).  In contrast import-minimal
does this

   Import the smallest key possible. This removes all signatures except
   the most recent self-signature on each user ID. This option is the
   same as running the --edit-key command "minimize" after import.
   Defaults to no.

But I am sure you know this.  What Am I misreading?


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users