Re: Your Thoughts

[Robert J. Hansen]

> GnuPG is cross-platform and in no way tied to Linux, but I think you
> have a point about the CLI-focused design of it. The problem isn't that
> it's CLI-based per se, but that this design has made it far too easy for
> it to accumulate features without much consideration for how the whole
> thing works together.

Eh.  Yes, no.  I agree with the claim that GnuPG's "we-do-it-all"
approach is overall a net negative for security: but there's a strong
argument to be made that if GnuPG didn't do it all, it wouldn't get done
at all.

Remember that for about fifteen years GnuPG received basically nil for
funding.  For a long while each Christmas I'd run a fundraiser match for
GnuPG, where I'd match dollar-for-dollar every dollar donated to GnuPG
for development.  My donation capped at $500.  For several of those
years, I was one of the largest individual contributors to GnuPG.

During that long period when GnuPG was short of funds and developers, it
could have focused on just one part of the crypto puzzle.  "This will
verify operating system packages with OpenPGP" or "this will verify
emails with OpenPGP", to use one simple distinction.  But doing that
would've left the other, just as important, need unaddressed: so the
developers did their best to make one package be useful to as many
OpenPGP users as possible.

This approach created some problems.  Some of the Efail bugs were
created when GnuPG generates output data even though the file fails
integrity checks.  This is not behavior you want in an email crypto
engine: if the email fails, you want to just bomb out and create no
data.  But this *is* behavior you want in a bulk crypto engine, where
there is no reasonable way to store petabytes of encrypted data in RAM
to check for consistency before writing to disk.

___
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?

[Mirimir via Gnupg-users]

On 07/01/2019 07:29 AM, David wrote:



> My take on all this is that I have had to disable Enigmail because it's
> screwed - I was not able to send mail and all the settings in enigmail
> were lots of  so I have been infected :(
> 
> David

Damn. But all is likely not lost.

If you can open Enigmail Preferences, go to the Keyserver tab, and
specify only keys.openpgp.org as the keyserver. That way, if you manage
to fix gpg, Enigmail won't break it again. Also see "100% CPU usage
endles loop of gpg --list-keys"  for
background.

About hardening and fixing gpg, see
 at
Mitigations and Repairs. Also see
.

You'll very likely need to use gpg in terminal. I suspect that GPA may
be just as wedged as Enigmail.

Maybe someone could post a step-by-step guide for fixing gpg. For people
who don't commonly use it in terminal. I suppose that I could import one
of the poisoned keys in a fresh VM, and explore how to fix it. But I'm
sure that someone reading this could just dash it out.

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

Re: Your Thoughts

[Alyssa Ross]

> I think also (sorry to say this Werner!) the problem is that
> GnuPG is Linux cli based and not like MacPGP from Mr. Zimmermann,
> back in the 90's was GUI based with much lesser commands and
> easier to learn. There was back then no Enigmail or other
> MUA plug-ins and you could simply copy and paste your messages.

GnuPG is cross-platform and in no way tied to Linux, but I think you
have a point about the CLI-focused design of it. The problem isn't that
it's CLI-based per se, but that this design has made it far too easy for
it to accumulate features without much consideration for how the whole
thing works together.

For example, why isn't ask-cert-level a default? I'm guessing it's just
because at some point it didn't exist, and the developers didn't want to
make a backwards incompatible change. But it means that, out of the box,
signatures on other keys are next to useless, because it's not possible
to specify how carefully you've checked a key. This leads to people only
signing keys that they've very carefully checked, and makes it so that
marginal signatures see almost no use, which I think has likely been a
major contributor to the failure of the web of trust.

A large part of what makes alternative encryption software like Signal
successful is its simplicity. I don't have to worry about the 3000
different setting combinations available to me, because there's design
work been put into it to set me up for success out of the box. I've
spent hours of my life learning about how to use GnuPG, and have ended
up with a way of using it that seems completely different to anybody
else's, but I still don't think I'm doing it right. It's not possible to
figure out how to use it as intended, because there's no intended way to
use it. There's no high level design for how people are supposed to use
the software. And without that, it's never going to be possible to use
GnuPG properly no matter how much time one is willing to invest.


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

Re: SKS Keyserver Network Under Attack

[Alyssa Ross]

> And yes, hkps://keys.openpgp.org would fall over and die if too many
> users started using it. So cert poisoning will be an issue until there's
> a secure alternative.

Just as a point of interest, I've talked to the people running
keys.openpgp.org about their capacity in #hagrid, when we were exploring
whether to change the default keyserver in Nixpkgs' GnuPG[1] (which we
ended up doing).

The impression I got was that they're very optimistic about their
ability to handle traffic to their server -- they were happy to have a
distro make the switch, and will be changing the defaults in Enigmail
and OpenKeychain very soon, as I understand it.

It is a real shame that a decentralized Hagrid isn't really possible,
though, at least to my understanding. It's quite the limitation for
GnuPG.

[1]: https://github.com/NixOS/nixpkgs/pull/63952


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]

Ryan McGinnis via Gnupg-users wrote:

> 
> Null modem transfer of your messages?  Yikes.  To me that’s the issue with
> PGP in general as it relates to secure communications - the nerds and the
> criminals and the spies know how to work it, but your average end user
> doesn’t need their step one to be “go to a Goodwill in a city you don’t live
> in wearing a disguise and buy a laptop with cash”, they need PGP to almost be
> automatic.  Think of how easy it is to bootstrap Signal and how hard you’d
> have to try to accidentally send something cleartext over that application.
> Linking your key to a new device is as easy as scanning QR code. Perfect
> forward secrecy, rich media, voice and video synchronous communications
> upgrades, you name it.  And my grandma could probably set it up without
> help.  I guarantee most big data scooping intelligence services are a lot
> more worried about OpenWhisper protocol than PGP because *people actually use
> it*.  Just being caught with WhatApp in China can get you sent to a camp,
> depending on your ethnicity.

Not to be off-topic, but you gave me the keyword "China" ...

I just recently found this and was wondering what purpose it
serves? Are people in China also allowed to use GnuPG?

pgp.ustc.edu.cn/

Regards
Stefan

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

Re: Your Thoughts

[Ryan McGinnis via Gnupg-users]

Null modem transfer of your messages?  Yikes.  To me that’s the issue with PGP 
in general as it relates to secure communications - the nerds and the criminals 
and the spies know how to work it, but your average end user doesn’t need their 
step one to be “go to a Goodwill in a city you don’t live in wearing a disguise 
and buy a laptop with cash”, they need PGP to almost be automatic.  Think of 
how easy it is to bootstrap Signal and how hard you’d have to try to 
accidentally send something cleartext over that application.  Linking your key 
to a new device is as easy as scanning QR code. Perfect forward secrecy, rich 
media, voice and video synchronous communications upgrades, you name it.  And 
my grandma could probably set it up without help.  I guarantee most big data 
scooping intelligence services are a lot more worried about OpenWhisper 
protocol than PGP because *people actually use it*.  Just being caught with 
WhatApp in China can get you sent to a camp, depending on your ethnicity.


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

‐‐‐ Original Message ‐‐‐
On Monday, July 1, 2019 10:26 AM, Stefan Claas via Gnupg-users 
 wrote:

> Andrew Gallagher wrote:
> 

> > On 2019/07/01 15:13, Stefan Claas via Gnupg-users wrote:
> > 

> > > I agree with Professor Green. Maybe he and his students can
> > > program a POC something more simple, preferably in Golang and
> > > while using the NaCl* library.
> > 

> > Golang? Not Rust? :-P
> 

> He he, I have tried to compile sequoia-pgp under Windows 10
> and failed miserably, do to the "excellent" compile instructions
> for Windows. I played with Rust in the past, under macOS, and
> never had problems.
> 

> What I would like to do is to create a binary of sequoia-pgp under
> Windows 10 and then use the binary under Windows 7, offline.
> 

> With Golang it would be no big deal, because that is super easy,
> but as understood the openpgp libs for Golang are not so good
> as the Rust ones.
> 

> > Who wants to copy and paste messages? That's s 1995.
> 

> Me for example :-) Why? I use encryption toolsoffline
> on my Notebook and then copy/paste the encrypted messages
> into CoolTerm to transfer them then via my USB to USB Nullmodem
> cable to my online computer. :-)
> 

> > > A real "modern" GnuPG should be IMHO the same as PGP was GUI based
> > > back then. The GUI could be also cross-platform QT based, for
> > > example.
> > 

> > You can't script a GUI, but you can GUI a CLI - and there is no shortage
> > of decent GUI interfaces for GnuPG.
> 

> I am aware of that, but I do have (Golang) tools which work as cli
> tools and they can be used with an extra written GUI program, if
> someone likes to do so. Very handy!
> 

> Regards
> Stefan
> 

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

 communications

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: Some thoughts on the future of OpenPGP and GnuPG

[Stefan Claas via Gnupg-users]

karel-v_g--- via Gnupg-users wrote:

> Hello!

[snip]

Hi Karel,

I think *flame on* Werner does not need to change anything,
because he is in the lucky position do get financed by
the big boys, so I see no need for him to start doing something
new like many others (with no financial support) do. Plus he
has the big openpgp community behind him, which supports him too.
(I have nothing against Werner, he can make millions!)

I also used PGP since the mid 90's and later used PGP and finally
GnuPG. Nowadays I use the super cool box* (plus base91 as armor)
with friends and for .pdf documents I use eIDAS conform signatures,
so that I am compatible in the EU. I also experimented with
encrypted Fax documents, but the armor GnuPG uses produces to
many erros with OCR FOSS software. I had better luck with codegroup
armor and Googles OCR, when uploading encrypted documents.

If you like to use other solutions besides GnuPG I would google
for it, like something like this etc. and check github too:

https://ianix.com/pub/curve25519-deployment.html

*https://github.com/rovaughn/box

Regards
Stefan



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

Re: Your Thoughts

[Juergen Bruckner via Gnupg-users]

Hello to all,

Am 01.07.19 um 00:23 schrieb Ryan McGinnis via Gnupg-users:
> Does anyone know what PGP’s peak adoption rate was?  I always loved it in 
> concept but very very rarely saw people actually trying to use it in the 
> wild, outside of the types of people who read this list.  


Well that not pretty "in the wild" but its pretty new:
The Austrian Parliament and some parts of the Austria Government have
released a website [1] where the PGP-Keys of Members of the Parliament
and other people in the government are collected on one place.

regards
Juergen

[1] https://gvkeys.at/

-- 
Juergen M. Bruckner
juer...@bruckner.tk



smime.p7s
Description: S/MIME Cryptographic Signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Some thoughts on the future of OpenPGP and GnuPG

[karel-v_g--- via Gnupg-users]

Hello!
Just right now I have read about a security vulnerability in the PGP 
keyservers, that can likely not be fixed according to Heise Online.
That makes me writing about something I have been thinking of for quiet some 
time now:
I am working in an environment that deals with highly sensitive personal data 
and my first PGP-key dates back to as far as the mid 1990s. Meanwhile I have 
changed it a few times, going from PGP 2.3 to the DH/DSS-Keys propagated by PGP 
5 and then back to RSA-Keys with GnuPG.
When looking at my In- and Outbox over the whole time I can safely say that I 
received and send only about 25 (!) mails in all the years and that many of my 
contacts simply have no PGP or don't use it any longer. It is easier and more 
reliable to send sensitive data by fax or mail for them.
Many attempts to make mail encryption easier have failed and the standards we 
have for it are aging. S/MIME was never repaired after the so called 
efail-attack and OpenPGP relies on a SHA1-based modification detection code to 
protect from it as far as I know. Many other aspects are also far from moderns 
standards.
Beyond this the complicated (and now dysfunctional as stated above) 
keydistribution caused many people to either send mails unencrypted, use 
regular mail or fax or use encrypting messengers nowadays.
The renewal of the OpenPGP-standard has stopped or stalled last year and the 
additions to GnuPG were also rather small in the past years (aside from ECC).
So my question as a user with a need for strong mail encryption is, whether it 
is not a time to start over with an all new encryption standard replacing 
OpenPGP and S/MIME completely. Something like the much praised Wireguard is 
doing right now in the VPN-world.
Implementing just one (or two if needed) standardized modern method for each of 
the following basic components: s2k-function, hash algorithm, authenticating 
symmetric crypto-algorithm, one ECC-based and one conventional asymmetric 
crypto-algorithm. And somethin to ease the key distribution. OPENPGPKEY and WKD 
might be suitable for that.
Thats it. No backwards compatibility. All new lean and easy. In my experience 
there are so few people actually using OpenPGP and these are crypto experienced 
so they should eysily adopt the modern proposal. If really needed the old 
standards could be supported for some time in a seperate "classic" component, 
but without the ability to create new keys.
To propagate the distribution of this hypothetical new format it might be 
useful to get some of the major mailproviders, business software companies and 
mail software vendors might be useful, another problem of OpenPGP was and is 
that aditional software components are needed.
Once again: I know that won't be easy or perhaps it can't be done at all. I 
really appreciate the work and commitment of Werner and all the others here and 
I am donatig each year to support them. But their work is simply not working in 
the real world. Sorry to say so, but that's my eperience and view  as a user 
-or let's better say wannabe user as there is no one to write encrypted mails 
to... ;)
Thanks for reading and discussing!
Karel

___
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 2019/07/01 17:26, Werner Koch wrote:
> p.s.
> As stop-gap solution the next gpg release sports a
> --keyserver-options self-sigs-only to allow importing of spammed keys.

I think this deserves more than a P.S. ;-)

-- 
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: distributing pubkeys: autocrypt, hagrid, WKD

[Werner Koch via Gnupg-users]

On Mon,  1 Jul 2019 10:27, konstan...@linuxfoundation.org said:

> - subkey changes

An expired key triggers a reload of the key via WKD or DANE.  Modulo the
problems I mentioned in the former mail.  For new subkeys we have a
problem unless we do a regular refresh similar to what should be done
for revocations.

> - UID additions/revocations

A new UID will automatically be fetched, so this is not a problem.  For
revocations the same as above is true.

> - expiration date extensions

What do you mean by this?  gpg --quick-set-expire and how this relates
to the Web Key Directory?




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: distributing pubkeys: autocrypt, hagrid, WKD (Re: Your Thoughts)

[Werner Koch via Gnupg-users]

On Mon,  1 Jul 2019 15:13, gnupg-users@gnupg.org said:

> distribution keys in Gentoo.  However, the main problem with WKD right
> now is that AFAIK GnuPG doesn't support refreshing existing keys via WKD

Actually gpg updates expired keys via WKD.  However, to not break things
and not to go out and do a query on the mail domain, this is only done
if the key has originally been fetched via WKD.

That turned out to be a too conservative approach and thus I consider to
change this so that gpg always tries to update an expired key via the
WKD.

Regarding a manual refresh there is indeed only a clumsy set of options
and commands but if we can agree to stop using --search-keys with
keyservers, this command can be used as a forceful update via WKD.


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: New keyserver at keys.openpgp.org - what's your take?

[Werner Koch via Gnupg-users]

On Mon,  1 Jul 2019 14:55, andr...@andrewg.com said:

> Yes, which is why we've informally had "let the owner choose whether to
> publish her incoming certifications" as best practice for a long time.

Actually gpg has always set the /Key Server Preferences/ to 

   First octet: 0x80 = No-modify
   the key holder requests that this key only be modified or updated
   by the key holder or an administrator of the key server.

assuming that at some point in the near future we would come up with a
scheme to actually allow to implement such a verification.  The problem
here is that PGP-5 and thus OpenPGP continued to use the PGP-2 model and
didn't defined key-signature as, for example, embedded signatures or
something similar.  We had no other chance here because the WoT was
heavily used for real and for ranking games.

Given that all public keyservers (there used to be others) didn't
verified any signatures it was not possible to implement an upload
scheme which guaranteed that key-signatures had been confirmed by the
key holder.  It has already been mentioned that this would have gone
against the design of the keyserver network to be a perpetual storage
system.  I recall that we discussed all these issues at the keyserver
admins conference in Utrecht back in 2000 and planned to do something
about it.  However, PGP Inc. was soon sold and interest in doing
something with the decentralized keyservers network diminished.  The new
SKS thing then made keyservers working for OpenPGP (the original HKP was
severely limited in accepting OpenPGP keys) but we all knew that if we
ever get really successful with OpenPGP the keyserver would not be able
to solve the key distribution task.  In fact we are here too similar to
X.509 and their CRL and OCSP problems.

> Cross-signing would enforce this, but the client-side tooling is lacking.

Cross-signing is not an easy solution because it can create a catch-22:
You can only import a key which has been cross-signed but for
cross-signing it needs to be imported.

An approval of a key signature by a self-signature would be the right
way - but a straightforward scheme would break the existing WoT and,
worse for some, the ranking.

The other and more important question is whether the WoT and thus
classical key signatures solve a real world problem for the _masses_.  I
doubt that and I can live without public (exportable) key-signatures.
Local key signatures are still a good idea as an annotation of imported
keys.


Salam-Shalom,

   Werner



p.s.
As stop-gap solution the next gpg release sports a
--keyserver-options self-sigs-only to allow importing of spammed keys.

-- 
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: Your Thoughts

[Stefan Claas via Gnupg-users]

Andrew Gallagher wrote:

> On 2019/07/01 16:26, Stefan Claas via Gnupg-users wrote:
> > I use encryption tools *offline*
> > on my Notebook and then copy/paste the encrypted messages
> > into CoolTerm to transfer them then via my USB to USB Nullmodem
> > cable to my online computer. :-)
> 
> That seems excessively baroque. What's your threat model? Is it really
> so dire that Tails isn't sufficiently sandboxed for you?

My thread model is actually low, but my Linux Notebook was recently
hacked and I don't trust my Windows 10 PC. I also had a couple of
days ago a "nice" thing happen, that when sending a messsage in German
from my VPS it arrived with other text content in Cyrillic at Gmail,
in real time, so to speak. Cool, eh?

Regardless if Tails or Linux etc. I no longer do encryption / decription
with online computers.

Seriously I think when using crypto tools in cli mode then users
should also try to do that offline and "celebrate" a bit the encryption /
decription procedure, unless of course they have a business running with
plenty of messages per day.

> 
> >> You can't script a GUI, but you can GUI a CLI - and there is no shortage
> >> of decent GUI interfaces for GnuPG.
> > 
> > I am aware of that, but I do have (Golang) tools which work as cli
> > tools and they can be used with an extra written GUI program, if
> > someone likes to do so. Very handy!
> 
> I agree that's the way user interfaces should be, but now I'm unclear
> what your complaint about GnuPG is, given that it's a CLI tool
> optionally wrapped in a GUI interface.

Sorry, there was no complaining intended from my side.

Regards
Stefan


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

Re: distributing pubkeys: autocrypt, hagrid, WKD (Re: Your Thoughts)

[Brian Minton]

I'm kind of a corner case, but I can't use wkd because I don't control
my top level domain for my email.   I also can't use DANE for the same
reason.  I can and do use DNS CERT records because it allows a
second-level domain. I suppose this has been discussed to death, but
wouldn't it make sense to only allow external signatures on a key if
they are cross-signed?  That should prohibit third parties from adding
junk to keys, but it doesn't prevent someone from making a key with
your email address in it.  I like the keybase.io approach of having
publicly verifiable signatures to match a key to an id, but it only
works for public ids such as github or facebook, rather than email.
In the case of verifying signatures (for e.g. software distribution),
just the id is needed, and no email is required.  But in the case of
encrypting to a stranger (for instance to send to a well-known
reporter or something), the only way to trust the key is if they
publicly sign something and put it on a publicly reachable website.
It seems that in several well-known cases, such as Snowden, he just
basically got lucky that the key in the keyserver network containing
the Guardian's email address was in fact them and not an impostor.  In
the case of say a mailing list, tofu works pretty well, but still
doesn't solve the problem of a cold communication with someone you've
never before seen a signed message from.

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

Re: distributing pubkeys: autocrypt, hagrid, WKD (Re: Your Thoughts)

[Brian Minton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Oops, forgot to sign it.

I'm kind of a corner case, but I can't use wkd because I don't control
my top level domain for my email.   I also can't use DANE for the same
reason.  I can and do use DNS CERT records because it allows a
second-level domain. I suppose this has been discussed to death, but
wouldn't it make sense to only allow external signatures on a key if
they are cross-signed?  That should prohibit third parties from adding
junk to keys, but it doesn't prevent someone from making a key with
your email address in it.  I like the keybase.io approach of having
publicly verifiable signatures to match a key to an id, but it only
works for public ids such as github or facebook, rather than email.
In the case of verifying signatures (for e.g. software distribution),
just the id is needed, and no email is required.  But in the case of
encrypting to a stranger (for instance to send to a well-known
reporter or something), the only way to trust the key is if they
publicly sign something and put it on a publicly reachable website.
It seems that in several well-known cases, such as Snowden, he just
basically got lucky that the key in the keyserver network containing
the Guardian's email address was in fact them and not an impostor.  In
the case of say a mailing list, tofu works pretty well, but still
doesn't solve the problem of a cold communication with someone you've
never before seen a signed message from.
-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQTu0BWAE9wubW4AHqQ3uVB6z/IBbgUCXRoW/QAKCRA3uVB6z/IB
bka7AP9DdmupTNZ0S7vC3BNxvIaVSkPgMvee5Kjk6SGWbgs6egD/Z08z2UVYzEoC
pSOA5HJmNDIQrOMZz2vUXL/ZA+OekwSIdQQBEQgAHRYhBPnEu3YOeD8N7BCmimuO
s6Blz7qpBQJdGhb+AAoJEGuOs6Blz7qp5n0A/A1cGVLBAI5XWAI2zvgoLpeIU7vU
lxucPzOQKSGWSJKpAP0X2LdUFg3kayoJvZZ2QntoZT7F2blAYXTUXTjvi75Wrw==
=xsw2
-END PGP SIGNATURE-

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

Re: Your Thoughts

[Andrew Gallagher]

On 2019/07/01 16:26, Stefan Claas via Gnupg-users wrote:
> I use encryption tools *offline*
> on my Notebook and then copy/paste the encrypted messages
> into CoolTerm to transfer them then via my USB to USB Nullmodem
> cable to my online computer. :-)

That seems excessively baroque. What's your threat model? Is it really
so dire that Tails isn't sufficiently sandboxed for you?

>> You can't script a GUI, but you can GUI a CLI - and there is no shortage
>> of decent GUI interfaces for GnuPG.
> 
> I am aware of that, but I do have (Golang) tools which work as cli
> tools and they can be used with an extra written GUI program, if
> someone likes to do so. Very handy!

I agree that's the way user interfaces should be, but now I'm unclear
what your complaint about GnuPG is, given that it's a CLI tool
optionally wrapped in a GUI interface.

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

[Stefan Claas via Gnupg-users]

Michał Górny via Gnupg-users wrote:

> On Mon, 2019-07-01 at 15:38 +0100, Andrew Gallagher wrote:
> > On 2019/07/01 15:13, Stefan Claas via Gnupg-users wrote:
> > > I agree with Professor Green. Maybe he and his students can
> > > program a POC something more simple, preferably in Golang and
> > > while using the NaCl* library.
> > 
> > Golang? Not Rust? :-P
> > 
> > I do find it odd how many projects make such a big deal of what language
> > they're written in. It shouldn't matter what language you use so long as
> > it works (and is memory safe).
> 
> I do find it odd how many projects choose exotic languages and then
> become defunct because few years later nobody wants to touch them. 
> Presuming you're still able to build them.  It's ironic people still
> don't see that even though SKS has just proven an example of that.
> 

As of my understanding Golang programmers are the highest paid programmers.
Sorry I no longer have the link to quote that!

BTW. Golang is from Google and if you check github project there always
plenty of Golang solutions available.

And the IMHO super cool thing of Golang is that if you cross-compile
on a Windows box it runs on Mac, Linux, Arm etc. and vice versa, very cool!

Regards
Stefan

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

Re: Your Thoughts

[Stefan Claas via Gnupg-users]

Andrew Gallagher wrote:

> On 2019/07/01 15:13, Stefan Claas via Gnupg-users wrote:
> > I agree with Professor Green. Maybe he and his students can
> > program a POC something more simple, preferably in Golang and
> > while using the NaCl* library.
> 
> Golang? Not Rust? :-P

He he, I have tried to compile sequoia-pgp under Windows 10
and failed miserably, do to the "excellent" compile instructions
for Windows. I played with Rust in the past, under macOS, and
never had problems.

What I would like to do is to create a binary of sequoia-pgp under
Windows 10 and then use the binary under Windows 7, offline.

With Golang it would be no big deal, because that is super easy,
but as understood the openpgp libs for Golang are not so good
as the Rust ones.

> Who wants to copy and paste messages? That's s 1995.

Me for example :-) Why? I use encryption tools *offline*
on my Notebook and then copy/paste the encrypted messages
into CoolTerm to transfer them then via my USB to USB Nullmodem
cable to my online computer. :-)
 
> > A real "modern" GnuPG should be IMHO the same as PGP was GUI based
> > back then. The GUI could be also cross-platform QT based, for
> > example.
> 
> You can't script a GUI, but you can GUI a CLI - and there is no shortage
> of decent GUI interfaces for GnuPG.

I am aware of that, but I do have (Golang) tools which work as cli
tools and they can be used with an extra written GUI program, if
someone likes to do so. Very handy!

Regards
Stefan

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

Re: Your Thoughts

[Andrew Gallagher]

On 2019/07/01 15:47, Michał Górny wrote:
> I do find it odd how many projects choose exotic languages and then
> become defunct because few years later nobody wants to touch them. 
> Presuming you're still able to build them.  It's ironic people still
> don't see that even though SKS has just proven an example of that.

I think we're criticising the same thing. Yes, I'm calling Golang (and
Rust) "exotic". :-)

Interestingly, Rust was first implemented in OCaml... (!)

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

[Michał Górny via Gnupg-users]

On Mon, 2019-07-01 at 15:38 +0100, Andrew Gallagher wrote:
> On 2019/07/01 15:13, Stefan Claas via Gnupg-users wrote:
> > I agree with Professor Green. Maybe he and his students can
> > program a POC something more simple, preferably in Golang and
> > while using the NaCl* library.
> 
> Golang? Not Rust? :-P
> 
> I do find it odd how many projects make such a big deal of what language
> they're written in. It shouldn't matter what language you use so long as
> it works (and is memory safe).

I do find it odd how many projects choose exotic languages and then
become defunct because few years later nobody wants to touch them. 
Presuming you're still able to build them.  It's ironic people still
don't see that even though SKS has just proven an example of that.

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

Re: Your Thoughts

[Andrew Gallagher]

On 2019/07/01 15:13, Stefan Claas via Gnupg-users wrote:
> I agree with Professor Green. Maybe he and his students can
> program a POC something more simple, preferably in Golang and
> while using the NaCl* library.

Golang? Not Rust? :-P

I do find it odd how many projects make such a big deal of what language
they're written in. It shouldn't matter what language you use so long as
it works (and is memory safe).

> There was back then no Enigmail or other
> MUA plug-ins and you could simply copy and paste your messages.

Who wants to copy and paste messages? That's s 1995.

> A real "modern" GnuPG should be IMHO the same as PGP was GUI based
> back then. The GUI could be also cross-platform QT based, for
> example.

You can't script a GUI, but you can GUI a CLI - and there is no shortage
of decent GUI interfaces for GnuPG.

> I also don't understand why GnuPG needs so many components, like
> pinentry, dirmngr and gpg-agent plus GnuPG itself, while MacPGP
> from Mr Zimmermann was only one program.

Most of those are separate because of security concerns. Monolithic
systems may look simpler from the outside, but they're often a bucket of
bolts on the inside. Role separation is your friend.

> *And regarding key formats, standards, RFC's etc. my new NaCl
> (pronounced salt) pub key which I use now with friends for email
> communication looks like this :-) :

Yes, it is possible to make very short public keys by stripping all
non-mathematical information and using ECC (SSH's ECC keys are similarly
terse). I'm skeptical of the long-term safety of ECC though (the NSA
appears to agree[1]) so while it may be worth using for session keys I'm
not going to trust it with my long-term identity. And the
non-mathematical information has its uses if you're maintaining any sort
of PKI.

[1]
https://blog.cryptographyengineering.com/2015/10/22/a-riddle-wrapped-in-curve/

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

[David]

On 01/07/2019 14:55, Andrew Gallagher wrote:
> On 2019/07/01 14:26, Robert J. Hansen wrote:
>> A thought that would unfortunately require an adjustment to the OpenPGP
>> spec itself: why do we put certification signatures on the target's
>> certificate, anyway?
> 
> I think it's mostly to do with key size. This works fine either way when
> it's among peers, but in large organisations you'll tend to get one key
> that certifies a large number of others, while the median number of
> certifications made by any of the other keys is zero. Better to
> distribute lots of keys each with one signature, than lots of keys with
> no signatures and one key with all the signatures.
> 
> Also, given that there tend to be a small number of super-certifiers, it
> is easier to trace back the possible verification paths given a list of
> certifiers on a newly-encountered key. The question is rarely "what is
> the list of the keys that I can verify?", and almost always "how can I
> verify this particular key?". X509 uses this model also, and for the
> same reason.
> 
>> The current debacle is completely the result of allowing *anyone* to
>> append a cert signature to *anyone else's* cert.
> 
> Yes, which is why we've informally had "let the owner choose whether to
> publish her incoming certifications" as best practice for a long time.
> Cross-signing would enforce this, but the client-side tooling is lacking.
> 
>>> * It MUST cryptographically verify all fetched material.
>>
>> Note that this amounts to "SKS must die".  SKS does no cryptographic
>> verification of material.
> 
> SKS as we know it must die, but I think that has been obvious for a
> while. Its reconciliation algorithm can live on, however. The crypto
> verification doesn't need to be performed in the synchroniser. It might
> be best if it didn't so that we don't run into potential issues re some
> systems being able to verify, a new algorithm and some not. Better to
> let the synchroniser just do its job, and move all the verification and
> caching stuff to a higher level. It need not be in the same binary.
> 
> 
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 

My take on all this is that I have had to disable Enigmail because it's
screwed - I was not able to send mail and all the settings in enigmail
were lots of  so I have been infected :(

David
-- 
People Should Not Be Afraid Of Their Government - Their Government
Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION
Becomes A DUTY! Join the Rebellion Today! https://gbenet.com

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

Re: distributing pubkeys: autocrypt, hagrid, WKD (Re: Your Thoughts)

[Konstantin Ryabitsev]

On Mon, Jul 01, 2019 at 03:13:29PM +0200, Michał Górny via Gnupg-users wrote:
The problem with autocrypt are the cases where its security measures 
are

tested. There is not good way to interact with the users in those cases.
I know this is not parts of its design goals, but it works against a better
user experience.

The progrem with hagrid (from what I've heard) is that it is again an attempt
of a validating keyserver, which means it has to centralize the trust
function or there is no point in the validation.

This makes WKD most mature and easiest for users in my eyes. (I was involved
in its design.).



I agree.  This is precisely why we've decided it for syncing
distribution keys in Gentoo.  However, the main problem with WKD right
now is that AFAIK GnuPG doesn't support refreshing existing keys via WKD
-- we had to employ a large hack to do it.


This can't be stressed enough. The main purpose of a managed keyring for 
communities like kernel.org and others is to advise all members of 
things like:


- subkey changes
- UID additions/revocations
- expiration date extensions

WKD doesn't currently facilitate any of these.

-K

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

Re: Your Thoughts

[Stefan Claas via Gnupg-users]

David wrote:

> Your Thoughts :)
> 
> https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/
> 

I agree with Professor Green. Maybe he and his students can
program a POC something more simple, preferably in Golang and
while using the NaCl* library.

I think also (sorry to say this Werner!) the problem is that
GnuPG is Linux cli based and not like MacPGP from Mr. Zimmermann,
back in the 90's was GUI based with much lesser commands and
easier to learn. There was back then no Enigmail or other
MUA plug-ins and you could simply copy and paste your messages.

A real "modern" GnuPG should be IMHO the same as PGP was GUI based
back then. The GUI could be also cross-platform QT based, for
example.

I also don't understand why GnuPG needs so many components, like
pinentry, dirmngr and gpg-agent plus GnuPG itself, while MacPGP
from Mr Zimmermann was only one program.

*And regarding key formats, standards, RFC's etc. my new NaCl
(pronounced salt) pub key which I use now with friends for email
communication looks like this :-) :

4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56

As you can see no infos about me, like email, name etc. and the
communications are authenticated and no need for signing messages
and no WoT or key servers! :-) Should also fit nicely on a business
card.

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?

[Andrew Gallagher]

On 2019/07/01 14:26, Robert J. Hansen wrote:
> A thought that would unfortunately require an adjustment to the OpenPGP
> spec itself: why do we put certification signatures on the target's
> certificate, anyway?

I think it's mostly to do with key size. This works fine either way when
it's among peers, but in large organisations you'll tend to get one key
that certifies a large number of others, while the median number of
certifications made by any of the other keys is zero. Better to
distribute lots of keys each with one signature, than lots of keys with
no signatures and one key with all the signatures.

Also, given that there tend to be a small number of super-certifiers, it
is easier to trace back the possible verification paths given a list of
certifiers on a newly-encountered key. The question is rarely "what is
the list of the keys that I can verify?", and almost always "how can I
verify this particular key?". X509 uses this model also, and for the
same reason.

> The current debacle is completely the result of allowing *anyone* to
> append a cert signature to *anyone else's* cert.

Yes, which is why we've informally had "let the owner choose whether to
publish her incoming certifications" as best practice for a long time.
Cross-signing would enforce this, but the client-side tooling is lacking.

>> * It MUST cryptographically verify all fetched material.
> 
> Note that this amounts to "SKS must die".  SKS does no cryptographic
> verification of material.

SKS as we know it must die, but I think that has been obvious for a
while. Its reconciliation algorithm can live on, however. The crypto
verification doesn't need to be performed in the synchroniser. It might
be best if it didn't so that we don't run into potential issues re some
systems being able to verify, a new algorithm and some not. Better to
let the synchroniser just do its job, and move all the verification and
caching stuff to a higher level. It need not be in the same binary.

-- 
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 1 Jul 2019, at 13:36, Andrew Gallagher  wrote:
> 
> We start from hagrid or something like it, and carefully add the ability
> to sync only the absolute minimum of data required to allow revocations
> to propagate. This probably means primary keys, their self-sigs and
> revocation sigs.

Or alternatively, we start with either hockeypuck or SKS (yes, I know) and 
carefully cripple them. 

Thinking about this a bit more, and with the DNS comparison in mind, it may be 
best if caching keyservers and validating keyservers were two entirely 
different things, to make sure we don’t accidentally open ourselves to a cache 
poisoning attack. 

A

___
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?

[Robert J. Hansen]

> We start from hagrid or something like it, and carefully add the ability
> to sync only the absolute minimum of data required to allow revocations
> to propagate. This probably means primary keys, their self-sigs and
> revocation sigs.

A thought that would unfortunately require an adjustment to the OpenPGP
spec itself: why do we put certification signatures on the target's
certificate, anyway?

If Alice 0xDEADBEEF certifies Bob 0xDECAFBAD, 0xDECAFBAD bears a
certification from 0xDEADBEEF.  Why not reverse it?  Why not, when
looking at a certificate 0xDEADBEEF that says "Hi, I'm Alice!", do we
not see "And I certify that 0xDECAFBAD is really Bob"?

In some respects it would permit us to preserve an append-only signature
model.  Only the certificate owner would be allowed to append a cert
signature to their cert.

The current debacle is completely the result of allowing *anyone* to
append a cert signature to *anyone else's* cert.

I am certain there's some subtle problem here I'm not seeing.  But it's
worth a thought.

> * It MUST cryptographically verify all fetched material.

Note that this amounts to "SKS must die".  SKS does no cryptographic
verification of material.

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

Re: distributing pubkeys: autocrypt, hagrid, WKD (Re: Your Thoughts)

[Michał Górny via Gnupg-users]

On Mon, 2019-07-01 at 12:18 +0200, Bernhard Reiter wrote:
> Am Montag 01 Juli 2019 01:36:41 schrieb Robert J. Hansen:
> > Now we've got Autocrypt, WKD, and Hagrid: of these Autocrypt is probably the
> > most mature and the easiest for email users.
> 
> The problem with autocrypt are the cases where its security measures are 
> tested. There is not good way to interact with the users in those cases.
> I know this is not parts of its design goals, but it works against a better
> user experience.
> 
> The progrem with hagrid (from what I've heard) is that it is again an attempt 
> of a validating keyserver, which means it has to centralize the trust 
> function or there is no point in the validation.
> 
> This makes WKD most mature and easiest for users in my eyes. (I was involved 
> in its design.).
> 

I agree.  This is precisely why we've decided it for syncing
distribution keys in Gentoo.  However, the main problem with WKD right
now is that AFAIK GnuPG doesn't support refreshing existing keys via WKD
-- we had to employ a large hack to do it.

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

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

[Andrew Gallagher]

On 2019/06/30 18:06, Daniel Kahn Gillmor wrote:
> On Sun 2019-06-30 00:33:22 +0100, Andrew Gallagher wrote:
>> Indeed, c) was exactly the killer use case I had in mind.
> 
> so, how do we get there?

We start from hagrid or something like it, and carefully add the ability
to sync only the absolute minimum of data required to allow revocations
to propagate. This probably means primary keys, their self-sigs and
revocation sigs.

(*Maybe* subkeys also, but it's probably unnecessary since distributing
new key material is less urgent than revoking existing material.)

We could repurpose the existing SKS recon protocol, but introduce
breaking changes: a) the protocol is versioned so that implementations
can gracefully degrade, and b) only whitelisted packet types are synced.

>> On the other hand, b) is also quite useful in the short to medium
>> term, until all mail providers decide to support WKD etc.
> 
> WKD is mighty nice, but it is not necessary.  For example, if you don't
> care about first-contact, Autocrypt is a totally reasonable key
> discovery mechanism.

Sure, but WKD and Autocrypt still don't collectively cover all the edge
cases, so some residual need for a keyserver-like system remains.

>> And considering that some companies still don’t fully support PGP/MIME
>> after nearly twenty years of being the preferred standard (I’m looking
>> at you, Apple), “short to medium” effectively means “indefinitely”.
> 
> If you know something specific about Apple failing PGP/MIME in some
> capacity i hope you'll be more explicit about it, because i don't know
> what you're talking about.

iOS's native Mail app cannot be replaced, and all third-party mail apps
must use its API which is less than fully-featured. Constructing a
PGP/MIME message requires access to the MIME headers that the Mail app
does not expose. All PGP apps under iOS must either cut and paste inline
PGP or encapsulate messages as attachments that Mail treats as black
boxes. PGP on iOS is therefore klunky as hell, and it's not going to
improve unless Apple makes a conscious decision to support it.

> Anyone who claimed
> keyservers were authoritative in the past was either confused or
> misleading you.

I am under no illusion that the keyservers are authoritative, don't worry.

A comparison with DNS may be useful. DNS is a distributed cached
database, but there is a distinction between primary, secondary,
recursive etc. Recursive resolvers make the system resilient, but the
primary is consulted regularly and the cache constantly invalidated.

(In DNS of course, the master is also considered authoritative, but this
does not automatically follow in a cryptographically validating system)

The keyservers make no distinction between primary and secondary - all
keyservers are equal, the provenance of data is thrown away, and the
cache can therefore never be invalidated. But provenance matters, and if
synchronising keyservers can't be primaries, something else should be.
That can be WKD, DANE, or just a plain URL on a server that I control.
Keyservers would then be mainly limited to caching information that was
obtained from some master keystore (with the exception of material
strictly required for revocations).

OpenPGP already has the "keyserver" field which is rarely used. It is
supposedly a hint to clients to tell them to prefer a particular
keyserver, but it could also be used as a hint to the keyservers
themselves, to tell them where the master copy of any public key can be
sourced.

> If you want to propose changes to
> https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistant-keystore
> i'd be happy to incorporate them too.

I'd suggest adding a "caching keystore", either after or as a subsection
of "updates-only keystore", with the following properties:

```
A caching keystore extends the concept of an updates-only keystore, by
supplying user IDs and third-party certifications on the condition that
they were recently available at an original location specified by the
key's owner. This mitigates key-flooding attacks by preventing arbitrary
submissions, and allows for the coordinated deletion of old or
problematic material by removing it from the original location.

* A caching keystore MUST accept submissions of primary keys as well as
cryptographically-valid self-certification and revocation sigs
(including third-party revocations) over those primary keys.

* It MAY synchronise the above key packets from other keystores. It MUST
NOT synchronise, or accept external submission of, any other packets.

* It SHOULD attempt to fetch and temporarily cache user IDs and incoming
third-party certifications over each primary key from the URL contained
in that primary key's "keyserver" field, if defined.

* If more than one "keyserver" definition is found for a given primary
key, then the most recent cryptographically-valid packet MUST take
precedence.

* It MUST cryptographically verify all fetched material.

* It MUST discard any unexpected 

distributing pubkeys: autocrypt, hagrid, WKD (Re: Your Thoughts)

[Bernhard Reiter]

Am Montag 01 Juli 2019 01:36:41 schrieb Robert J. Hansen:
> Now we've got Autocrypt, WKD, and Hagrid: of these Autocrypt is probably the
> most mature and the easiest for email users.

The problem with autocrypt are the cases where its security measures are 
tested. There is not good way to interact with the users in those cases.
I know this is not parts of its design goals, but it works against a better
user experience.

The progrem with hagrid (from what I've heard) is that it is again an attempt 
of a validating keyserver, which means it has to centralize the trust 
function or there is no point in the validation.

This makes WKD most mature and easiest for users in my eyes. (I was involved 
in its design.).

Regards,
Bernhard

-- 
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


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

Re: SKS Keyserver Network Under Attack

[Leo Gaspard via Gnupg-users]

Mirimir via Gnupg-users  writes:
>>- Embeds a hardcoded list of already-disrupted keys for which packets
>>  should be filtered-out when serving them
>
> That's what I meant. Plus some mechanism for testing keys, so poisoned
> ones are blocked, as soon as possible.
>
> It'd also be useful for SKS to report "this key has been poisoned", and
> suggest alternative sources, rather than just failing silently.

I think we can't rely on humans actually reading the output, even if
GnuPG was able to display the output on eg. `--refresh-keys` in a way
understandable by a human.

Also, the aim of my suggestion was to actually *not* block the
keys. This second point of part 1 is there to just filter some hardcoded
list of packets, thus making key updates still propagate.

The first point was there to prevent additional keys from being
poisoned, and the second to limit the damage caused by already-existing
keys -- the first one is unfortunately quite necessary, as
sks-keyservers can't reasonably be coordinating changes on the ~220
keyservers every time a new key gets poisoned (or even twice, for that
matter, one flag day is already bad enough)

>> Do you think such a plan might be reasonably done, to at least keep the
>> most basic functionality of not breaking existing installations and
>> allow them to keep revocations flowing? The biggest issue I can see is
>> it requires a quite big amount of development work.
>
> But less work than actually fixing SKS, right?

Well, nowadays “fixing SKS” means “making hagrid able to synchronize its
cryptographic-only content and propagate third-party signatures under
some circumstances”, as far as I understand.

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

Re: SKS Keyserver Network Under Attack

[Mark Rousell]

On 01/07/2019 10:54, Robert J. Hansen wrote:
>> I think not.
> Thankfully we live in free societies where dissent is allowed: on good
> days, even tolerated and encouraged.  You're wrong, of course, but
> please understand I encourage you to be wrong.  :)
>
> Also, if it isn't clear: although I emphatically disagree with you, this
> is not a personal dispute.  I plan on turning your idea into a pinata,
> but on a personal level as far as I'm concerned there's nothing but
> peace between us.

I can see that you are (rightly and understandably) very, very angry
that this has been done and that you have been personally targetted but
it nevertheless seems to me that it is not a childish act. Its very
carefully targetted nature strongly suggests to me that is was done to
produce specific results (which should actually be beneficial for the
community as a whole).

This does not mean that I condone the act. I do not! It was a bad thing
to do in this form.

>
>> You yourself say that the SKS system has had known problems for well 
>> over a decade and yet nothing has been done about it.
> No.  No.  No.  I have not said that.  In the last ten years the
> sks-de...@nongnu.org community has explored pretty thoroughly the
> problem space and concluded it cannot be solved at the SKS level, given
> the community's level of manpower and funding.

And yet, despite this, SKS is still in use and not currently fully
replaceable, as I understand it.

Is that not a problem of inertia? It certainly seems like it to me. No
natter what the issue of lack of manpower or lack of funding, if these
have not been overcome in 10+ years despite there being widely
recognised problems then that's inertia. (No, this is not
"victim-blaming". Read on for why not).

However, all is not so dark as it might seem. You go to say...

> In a very real sense, WKD, Autocrypt, Hagrid, dkg's work in
> abuse-resistant keyservers, and so forth, all sprang from the sks-devel
> community's recognition of the problem and the inability of SKS to
> effectively fix it.  If SKS were in better shape it's likely none of
> those projects would have ever started.

But this is good. It means that, in large part, inertia has in fact been
overcome from new directions. People have contributed to improving
things through innovation and new approaches.

It just needs to go that little bit further, it seems.

> There is a line of thinking which I find to be morally appalling, and
> you describe it quite clearly in your footnote:
>
>> 1: You referred to this inertia as "powerful technical and social 
>> factors" which is true but they still represent a bug, not a
>> feature. These factors are in effect societal excuses, not legitimate
>> reasons for lack of action.
> If the sks-devel community has repeatedly made it clear over the course
> of a decade that "we lack both the manpower and the financial resources
> to fix this problem", never receives manpower or financial resources,
> and then ten years later this happens... our reward is to be
> victim-blamed?  "If you were really serious you would've done something
> by now"?

Don't be silly. I was merely pointing out how change is sometimes needed
to overcome roadblocks. In corporate circles they (annoyingly enough)
call it "thinking out of the box".

Furthermore, I am not "victim-blaming" as you claim. Lack of manpower
and funding is not what I regard as victimhood. Lack of manpower and/or
finding is just normal life for many, many projects or human endeavours
and is a natural and normal issue that needs to be overcome somehow for
any project or endeavour of almost any type to initially succeed and
then to be maintained.

In my own case, I am involved in a project that I would dearly like to
do better and it is in fact held back by lack of both manpower and
funding. However, when people tell me that I need to overcome these
issues, no matter how difficult they are to overcome, I do not claim
victimhood or say that my critic is "victim-blaming" me. Instead I agree
and ask my critic for possible sources of manpower or funding, or for
other ways to address the issues that the project is intended to solve.
And you will note in the footnote I did in fact mention an initiative
that Eric S. Raymond is working on that might, at least in part, address
issues of funding. So I have not made the mistake of criticising without
at least offering some possible solution to the obvious problem.

>
>> of this community, they have brought absolutely unavoidable attention
>> to the fact that something needs to be done *now*.
> At a tremendous price.  A price that I, and many others, think is
> morally appalling.  These people are not our friends and have done us no
> favors.

Time will tell. Do you think that something substantive will now be done
that could not be done before because of previous lack of manpower or
funding?

Sometimes, the obvious and undeniable existence and public highlighting
of an egregious flaw prompts the new 

Re: SKS Keyserver Network Under Attack

[Alyssa Ross]

> Third-party signatures from locally unknown certificates are arguably
> not so useful, so how about using ?--keyserver-options import-clean??
> (Or even making it the default behavior?)  Of course it's not perfect as
> it still clutters network traffic and gpg(1) needs to clean up the mess
> client-side (which is slow and CPU expensive), but at least it mitigates
> the DoS attack: it doesn't prevent keyring updates, and limits the bloat
> on disk.

Alas, this doesn't fully mitigate the issue, because it's not exactly
difficult to get a key into somebody's keyring, especially with the
existence of the auto-key-retrieve option. All I would have to do would
be to sign the key of somebody in the strong set lots of times with
the same key, and then send you an email signed by me, and an email with
a body signed by the key I was attacking (I could find some sort of
statement signed by that key online somewhere). Alternatively, I could
construct a Git repository that would load the keys into your keychain
in the correct order when you examined the commit signatures if I could
find a commit signed by my victim somewhere. I'm sure it's easy enough
to get a public key imported even without auto-key-retrieve, too. I
imagine there are MUAs that would import a key attached to a message,
maybe.


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

Re: SKS Keyserver Network Under Attack

[Peter Lebbing]

On 01/07/2019 11:54, Robert J. Hansen wrote:
> [...]

I think this mail sums up the most important points about this whole
ordeal very well. I completely, wholeheartedly agree. I encourage
everyone to re-read it and internalise it.

The only point not touched upon in this specific mail, I think, is why
people who say that the damage that has been done is not of consequence,
are wrong.

It seems to me that rjh's and dkg's keys will be in many public keyrings
and in many (key) signature chains, and thus have the potential to cause
major problems for many people all around the world when they refresh
their keys. I'd say the consequences of poisoning precisely these
well-connected keys are pretty major. People who depend upon OpenPGP
will find their software is hung and timing out, even when they're not
trying to do anything with these specific public keys: often it's enough
the poison is on the keyring, as far as I can tell. Lacking the
knowledge to fix this, they will no longer be able to check signatures,
and probably be unable to read encrypted messages altogether.

For me, that'd be a nuisance.

For some people, it may have very large real-life consequences.

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 Keyserver Network Under Attack

[Robert J. Hansen]

> I think not.

Thankfully we live in free societies where dissent is allowed: on good
days, even tolerated and encouraged.  You're wrong, of course, but
please understand I encourage you to be wrong.  :)

Also, if it isn't clear: although I emphatically disagree with you, this
is not a personal dispute.  I plan on turning your idea into a pinata,
but on a personal level as far as I'm concerned there's nothing but
peace between us.

> You yourself say that the SKS system has had known problems for well 
> over a decade and yet nothing has been done about it.

No.  No.  No.  I have not said that.  In the last ten years the
sks-de...@nongnu.org community has explored pretty thoroughly the
problem space and concluded it cannot be solved at the SKS level, given
the community's level of manpower and funding.

That's not "nothing".  That's a very important result and it is
literally the most the sks-devel community can be asked or expected to
do, given their critical shortages of money and manpower.

In a very real sense, WKD, Autocrypt, Hagrid, dkg's work in
abuse-resistant keyservers, and so forth, all sprang from the sks-devel
community's recognition of the problem and the inability of SKS to
effectively fix it.  If SKS were in better shape it's likely none of
those projects would have ever started.

There is a line of thinking which I find to be morally appalling, and
you describe it quite clearly in your footnote:

> 1: You referred to this inertia as "powerful technical and social 
> factors" which is true but they still represent a bug, not a
> feature. These factors are in effect societal excuses, not legitimate
> reasons for lack of action.

If the sks-devel community has repeatedly made it clear over the course
of a decade that "we lack both the manpower and the financial resources
to fix this problem", never receives manpower or financial resources,
and then ten years later this happens... our reward is to be
victim-blamed?  "If you were really serious you would've done something
by now"?

It's like telling a doctor in the developing world who has for ten years
been screaming that she needs polio vaccine, after a polio epidemic
starts in her neighborhood, "the poverty is in effect a societal excuse,
not a legitimate reason for lack of action"?

It takes stuff to do stuff, and it's really rude to blame the victims
for problems they inherited but did not create.

> Well, someone has now brought widespread attention to the issue. By 
> poisoning the certificate of (at least) two very high-profile 
> members

Three now, since apparently Kristian has been hit.

> of this community, they have brought absolutely unavoidable attention
> to the fact that something needs to be done *now*.

At a tremendous price.  A price that I, and many others, think is
morally appalling.  These people are not our friends and have done us no
favors.

> Good can come of this attack on you and DKG.

I seem to recall people saying the same after 9/11: that yes it was a
horrific thing, but that "good can come of this tragedy".

I seem to recall people saying the same after my best friend's suicide:
that yes it was a horrific thing, but that "good can come of this tragedy".

It is the nature of goodness that, like hope, it springs eternal and in
the most unlikely of places.  But it is also barbarous to claim the good
that may come out of a horror should be counted to the horror's credit.


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

Re: Your Thoughts

[David]

On 30/06/2019 21:01, Ralph Seichter wrote:
> * da...@gbenet.com:
> 
>> Your Thoughts :)
> 
> I think the article is five years old, has not aged well (e.g. MUA
> integration has improved), and that nothing better than PGP has come
> along in the meantime.
> 
> Next. ;-)
> 
> -Ralph
> 
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 

I have used gnupg for years and converted just a handful to encrypt
their emails - and it's beyond my comprehension why it is that normal
people do not encrypt their emails by default.

Over the years GUIs have come along and gpg4win - perhaps people are not
that concerned about GCHQ and the NSA reading all their emails - they
read everything else from all thier devices.

We know FaceBook Google etc.. hand over all data to the NSA and GCHQ and
their are rumours that SSL has been cracked - am sure it has as my
website and database were hacked and my host provider had 3 mail servers
hacked in a matter of 3 days - much to their shock.

I think for Windows users gpg4win attempts to provide a GUI that makes
installation easy - but only geeks use it :)

I try to promote user encryption on my website (it's down at this time)
but very very few people take their daily lives seriously.

David


-- 
People Should Not Be Afraid Of Their Government - Their Government
Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION
Becomes A DUTY! Join the Rebellion Today! https://gbenet.com



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

Re: SKS Keyserver Network Under Attack

[Mark Rousell]

On 30/06/2019 13:44, Robert J. Hansen wrote:
> This has all the hallmarks of a child playing with matches and
> clapping with glee as the house catches fire.

I think not.

You yourself say that the SKS system has had known problems for well
over a decade and yet nothing has been done about it. In other words,
inertia has overruled both prudence and strategic avoidance of
predictable problems[1].

Well, someone has now brought widespread attention to the issue. By
poisoning the certificate of (at least) two very high-profile members of
this community, they have brought absolutely unavoidable attention to
the fact that something needs to be done *now*. As things stand, it's
still not too late for something to be done to protect the vast majority
of users and use cases.

Good can come of this attack on you and DKG.

Yes, as you say in your Gist, the attackers could have come to you and
worked together. But I can also understand why they didn't: This
approach has made waves, and sometimes waves are necessary to wake up a
community that really knows it should be taking action but hasn't done so.

Both you and DKG are clearly furious that you were targetted (and
rightly so!) but if 'lesser' members of the community had been attacked
in this way it's entirely possible that either no one would have noticed
or that it would not have had the radical shake up effect that this is
now having.

I'm not condoning an attack like this. In the UK (where I am located) it
is likely to be illegal, and it is probably illegal in other
jurisdictions. But I just don't see a "child [...] clapping with glee".

Instead it seems to me that the net result is that long overdue action
is now taking place.

Thank you for all your input into OpenPGP. Yes, it's made you a target.
But, despite the seemingly personal nature of this, it does seem that
good can come of it.

(And for the avoidance of doubt: I do not know who was behind this and
it was not me.)




Footnote:-
1: You referred to this inertia as "powerful technical and social
factors" which is true but they still represent a bug, not a feature.
These factors are in effect societal excuses, not legitimate reasons for
lack of action. As I write this, I fully appreciate the fact that very
few people receive remuneration for writing code or maintaining key
servers (or much of anything else connected with OpenPGP). But again,
perhaps this is also a bug of sorts. Perhaps there does need to be a way
for critical non-hierarchical Internet infrastructure like this to be
financed. Isn't Eric S. Raymond working on something like this right now?

-- 
Mark Rousell

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

Re: SKS Keyserver Network Under Attack

[Chris Narkiewicz via Gnupg-users]

> I must have missed the memo
> describing the exact nature of the problem.

https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users