Re: PGP Key Poisoner

2019-08-12 Thread Playfair via Gnupg-users
Juergen Bruckner via Gnupg-users wrote:
> Thats pretty interesting, but the author also says he did this as showcase.
> Nontheless, its not really good to have such a tool "in the wild", and
> even on a plattform like GitHub

A tool like this has been in the wild for several weeks.  As skeeto says
"Further, this attack has been known for years, and in 2019 it's been
used against real keys on keyservers. This tool is nothing new and does
not create any new capabilities. It's merely proof that such attacks are
very easy to pull off. It doesn't take a nation-state actor to break the
PGP ecosystem, just one person and couple evenings studying RFC 4880.
This system is not robust."

One wonders why an attack that's been known for years is only being
addressed now that it has been used.

> Am 11.08.19 um 23:47 schrieb Anonymous Remailer (austria):
>>
>> https://github.com/skeeto/pgp-poisoner
>>



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


Re: allow-non-selfsigned-uid issue with key from keys.openpgp.org that contains no identity information

2019-08-02 Thread Playfair via Gnupg-users
On 8/1/19 4:13 PM, David wrote:
> Playfair via Gnupg-users:
>> If keys.openpgp.org won't publish a user ID other than a verified email
>> address, is its only recourse to remove the user ID?  Could it instead
>> substitute the hex key ID, fingerprint or a dummy string like "User ID
>> not verified"?  If it can't, is there any benefit in publishing a
>> mutilated key people can't use?  Just reject it.
> 
> Why upload a key to a keyserver with no email address? What's the point
> of doing that?

The point of doing that is to permit people who obtain my key through
other channels, say directly from me, to periodically refresh it.  When
I revoke my key or change the expiration date, the fact will be
communicated to holders of my public key, at least to those who refresh
their key rings.

> You cant send an encrypted email to it - unless your
> given the email first -will it work to encrypt to a publlic key with no
> email?

Of course it works.  A correspondent has only to select my public key
when sending me email.  Easier still is for her to create an Enigmail
PRR associating my key with my email address or addresses.  That makes
key selection automatic.

> Keyservers should have strict rules on public keys - all to have a valid
> email a validation email sent back - then confirmed and that public key
> is then available. No identity available - simple - reject the key.

Sounds to me like you expect a key server to double as a CA.

Chuck



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


Re: allow-non-selfsigned-uid issue with key from keys.openpgp.org that contains no identity information

2019-08-01 Thread Playfair via Gnupg-users
On 8/1/19 7:37 AM, Werner Koch via Gnupg-users wrote:
> On Mon, 29 Jul 2019 09:43, gnupg-users@gnupg.org said:
>> it that way", i think.  Perhaps Werner can provide more background on
>> why GnuPG is generally resistant to holding OpenPGP certificates that
>> have no User ID at all in its local keyring.
> 
> The user ID is important because the accompanying self-signature conveys
> important information about the keyblock.  For example expiration date
> and preferences.  It is true that this can also be conveyed with
> direct-key-signatures (a self-signature directly on a key which was
> mainly introduced for dedicated revocations).  However, this is a not so
> well tested feature of gpg and my educated guess is that many other
> OpenPGP implementations do not handle direct-key signatures in a way
> compatible to pgp or gpg - if at all.  Thus by relying on them we would
> sail into uncharted waters.
> 
>> Doing such a merge would be super helpful, particularly for receiving
>> things like subkey updates and revocation information from
> 
> I agree that we can add a code path to import a primary key plus
> revocation certificate but without user-ids.  PGP however, does not
> support this and is the reason why we extended the revocation
> certifciate with a minmal primary key.
> 
> Update of subkeys is a different issue and I see no solid use case for
> allowing that without user-id (cf. expiration date of the primary key).

Couldn't this issue be dealt with by the key server instead of by
OpenPGP implementations?  GnuPG can create and import keys having
non-email-address user IDs.  A string of more than 4 characters is
acceptable.  Anything remotely resembling an email address, e.g.
x...@y.xyz, is okay.

If keys.openpgp.org won't publish a user ID other than a verified email
address, is its only recourse to remove the user ID?  Could it instead
substitute the hex key ID, fingerprint or a dummy string like "User ID
not verified"?  If it can't, is there any benefit in publishing a
mutilated key people can't use?  Just reject it.

Chuck




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