Re: was Re: PGP Key Poisoner // now "Binding one person's subkey to another person's primary key"

2019-08-14 Thread Robert J. Hansen 
> I've often wondered why the sks software didn't require
> cross-certification.  It seems like that would solve the key poisoning
> issue.

Not enough OCaml programmers, mostly.

Strange but true: SKS has no crypto code in it anywhere.  So the moment
you say "I wonder why SKS doesn't do this thing that involves crypto,"
well, that's the answer: because it involves crypto and nobody has ever
added that capability to SKS.

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

Re: PGP Key Poisoner

2019-08-14 Thread Johan Wevers 
On 14-08-2019 11:38, Alessandro Vesely via Gnupg-users wrote:

> Of course, anonymous key poisoning is a kind of gratuitous vandalism.
>  Yet, crypto is supposed to work in a hostile environment.

But this is only an extreme form of what an old keyserver already did:
it issued (I believe every 6 months) a new signature. Arguments about
DoS attacks were already given then.

-- 
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html


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

Re: was Re: PGP Key Poisoner // now "Binding one person's subkey to another person's primary key"

2019-08-14 Thread Brian Minton 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I've often wondered why the sks software didn't require
cross-certification.  It seems like that would solve the key poisoning
issue.  It would mean that when signing someone's key, you'd have to
have a way to exchange the signatures first, before submitting them to
the keyserver network.  However, I think that most keysigning parties
do that anyway, not to mention software like caff.
-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQTu0BWAE9wubW4AHqQ3uVB6z/IBbgUCXVRTFwAKCRA3uVB6z/IB
bqAKAQC4mzwJSUj52Wls65QJqOdZNFvEx8yozIeCDtb/+XWdtAD7BALPm3Z9/5oI
ZAjPE5b9EX1sddZpdj2+DuvbKZKoDQeIdQQBEQgAHRYhBPnEu3YOeD8N7BCmimuO
s6Blz7qpBQJdVFMvAAoJEGuOs6Blz7qpCMgA/35Ni8l2Cb/EdHP3AhmkbHJAVGHo
7AeDnRHGcgre6M1CAPwO8IoTd8l69z2Rn0YzXwakHfNQlp9+OPg6U+mUj9eImw==
=v1zo
-END PGP SIGNATURE-

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

Re: PGP Key Poisoner

2019-08-14 Thread Alessandro Vesely via Gnupg-users 
On Tue 13/Aug/2019 12:08:31 +0200 Werner Koch Via Gnupg-users wrote:
> On Tue, 13 Aug 2019 09:54, gnupg-users@gnupg.org said:
> 
>> The bug, however, is in the program that chokes on poisoned keys!
> 
> Nope.  This is a long standing DoS protection by limiting the total
> length of a keyblock.  The diagnostics were a bit misleading, though.
> 
> The time it took to process all these signatures during importing is due
> to a fix and out of order keyblock functions which has been enabled by
> default in 2.1.  It should be obvious that checking several thousands of
> signatures and finding the matching user-id takes its time.
> 
> Anyway, given that these keys are real the approach with 2.2.17 is to
> auto-retry an import with import-clean etc. if the keyblock size hits
> the size limit.  For keyserver imports import-clean is also the default.


Why wasn't that check in place from version 0.0.0?  Perhaps GnuPG was
coded at times when DoS was an operating system?

Of course, anonymous key poisoning is a kind of gratuitous vandalism.
 Yet, crypto is supposed to work in a hostile environment.


Best
Ale
-- 








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

Re: was Re: PGP Key Poisoner // now "Binding one person's subkey to another person's primary key"

2019-08-13 Thread vedaal via Gnupg-users 



On 8/13/2019 at 7:59 AM, "Kristian Fiskerstrand" 
 wrote:

>As you correctly point out its really not that relevant for 
>encryption
>subkeys. It does have security implementations for signing 
>subkeys; see
>[cross-certification section] for some details on that.
>
>References:
>[cross-certification section]
>https://gnupg.org/faq/subkey-cross-certify.html


GnuPG has been requiring cross-certification for a very long time, 
which would mean that an attacker who attaches a person's listed subkey to a 
different masterkey, 
would still not be able to do anything with it, because the attacker can't make 
it cross-certify.

Being simplistically naive here,
How difficult would it be to get keyservers to agree that only the key owners 
can submit new signatures to their own keys?
(i.e., The owner's detached signature of the public keyblock having the new 
signature, required together with any submitted key with a new signature.) 

A Denial-of Service attack will still always be possible against a keyserver, 
since it is easy for an attacker to generate a large volume of legitimate keys, 
with only a self-signature, 
and upload them to the keyserver,
but at least then, no individual key by a real user, could be attacked.


vedaal


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

Re: PGP Key Poisoner

2019-08-13 Thread Peter Lebbing 
On 13/08/2019 17:11, Robert J. Hansen wrote:
>> I think the proper fix is to design an alternative to the SKS keyserver
>> network. The design choices in the reconciliation protocol don't work
>> out anymore, we shouldn't change the protocol but replace it.
> 
> I agree.

Ah, then the discussion about OCaml is a moot point by now and can be
disregarded until the moment someone proposes to write the replacement
in OCaml :-D

Cheers,

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: PGP Key Poisoner

2019-08-13 Thread Robert J. Hansen 
> I don't think the bit about the OCaml code complexity was a good
> argument in Rob's gist post.

In my defense, I wrote that front-to-back in under an hour.  My goal was
to quickly release a useful précis, not to slowly write a definitive
reference on the problem.  :)

That said, this particular thing I stand behind.  The number of people
in the SKS community who grok OCaml is pretty close to zero.

> I think the proper fix is to design an alternative to the SKS keyserver
> network. The design choices in the reconciliation protocol don't work
> out anymore, we shouldn't change the protocol but replace it.

I agree.

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

Re: PGP Key Poisoner

2019-08-13 Thread Stefan Claas via Gnupg-users 
Peter Lebbing wrote:

> > I wonder why those SKS key servers are so important to be still in
> > service as of today since we have WKD, Hagrid, keybase, Mailvelope Key
> > Server and Facebook?
> 
> Only people using the SKS keyserver network are affected by this issue.
> You say you don't see a reason to use them. So don't. Tell your
> correspondants to use different methods when they exchange keys with
> you, and you'll never have to interact with the SKS keyserver network
> again. Problem solved; for you. Others will take care of their own.
> 
> Also Facebook?
> 
> A lot of the alternatives to the SKS network have some issues regarding
> either a form of trusted third party, or of anonymity. Every service has
> its own trade-offs. And some stand out like a sore thumb. Again...
> Facebook?! :-)

True, I will let them know. Regarding Facebook, yes, I see at as some form
of a key server too because it allows FB users to upload their pub key
to their profile. :-)

Regards
Stefan

-- 
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD)

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

Re: was Re: PGP Key Poisoner // now "Binding one person's subkey to another person's primary key"

2019-08-13 Thread Peter Lebbing 
On 13/08/2019 13:56, Kristian Fiskerstrand wrote:
> As you correctly point out its really not that relevant for encryption
> subkeys. It does have security implementations for signing subkeys; see
> [cross-certification section] for some details on that.

But this issue has been fixed for so long that any CD's documenting the
fix will have since bit-rotted! It's ancient Information Technology
history!

To be exact, this has been a non-issue since GnuPG 1.4.8, released
2007-12-20, which defaulted to --require-cross-certification after the
cross certifications had percolated through the ecosystem in the years
leading up to that new default.

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: PGP Key Poisoner

2019-08-13 Thread Peter Lebbing 
On 12/08/2019 22:09, U'll Be King Of The Stars wrote:
> The things I missed are:
> 
> - how to check and clean a user's local keyring
> 
> - how to update the user's local configuration in ~/.gnupg

I generally felt there was a lack of concise, complete instructions for
users, after the event. I was missing several pieces of the puzzle
myself. Still, I suppose I could have tried to do this, so it's a bit
odd to be pointing out that this area was lacking when I could have
solved it partially myself. But here we are: I never saw a good concise
complete set of instructions and guidance, and I was a bit surprised
no one wrote it.

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: PGP Key Poisoner

2019-08-13 Thread Peter Lebbing 
I suspect we haven't seen this issue being done in the real world before
because it is not a useful attack in many scenarios. It's just a nasty
DoS that can be avoided by not using the SKS keyserver network. I'm
completely speculating, but I think that the people who really want to
learn something about their victim will use and have used completely
different attacks. This DoS isn't effective at what they want.

I don't know if that is the case, but I think it's a possibility.

This doesn't mean that this attack was harmless; far from it. I think it
has the potential to do a lot of harm to a lot of people. It just
possibly doesn't really accomplish the goals that, for instance,
oppressive regimes or black hats penetrating networks have. And since no
serious attacker used this weakness, by that virtue it might not be a
big problem. The good sides of the SKS keyserver network might outway
its flaws when the flaws are not the flaws that attackers will exploit
in practice.

Until little boys with matches come round and play at being responsible
security researchers without understanding how that actually works.

> People know there that there are issues for a decade with the software
> running on their servers and they don't understand the codebase to fix
> issues.

I don't think the bit about the OCaml code complexity was a good
argument in Rob's gist post.

I think the proper fix is to design an alternative to the SKS keyserver
network. The design choices in the reconciliation protocol don't work
out anymore, we shouldn't change the protocol but replace it.

Several alternatives for key distribution have actually been developed
for many years now. You can't say people are not actively working on
this problem, it's just not true. That they are actually looking in a
different solution space than what you want to see is their right.

> And when things later happen, like recently, they still run their
> servers.

Perhaps because there are still users who need it. GnuPG 2.2.17 already
led to a report[1] on the mailing list that they needed third-party
signatures from keyservers. I don't know if they need the SKS network,
but in general, there are users out there who can still use it.

But I obviously can't speak for anyone else.

> I wonder why those SKS key servers are so important to be still in
> service as of today since we have WKD, Hagrid, keybase, Mailvelope Key
> Server and Facebook?

Only people using the SKS keyserver network are affected by this issue.
You say you don't see a reason to use them. So don't. Tell your
correspondants to use different methods when they exchange keys with
you, and you'll never have to interact with the SKS keyserver network
again. Problem solved; for you. Others will take care of their own.

Also Facebook?

A lot of the alternatives to the SKS network have some issues regarding
either a form of trusted third party, or of anonymity. Every service has
its own trade-offs. And some stand out like a sore thumb. Again...
Facebook?! :-)

Cheers,

Peter.

[1] 

-- 
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: was Re: PGP Key Poisoner // now "Binding one person's subkey to another person's primary key"

2019-08-13 Thread Kristian Fiskerstrand 
On 12.08.2019 19:09, vedaal via Gnupg-users wrote:
> Can this really be done?
> 
> (Does not matter so much to me personally, as I grew up with v3
> keys, and even when using a V4 key, I don't generate a subkey, but
> allow all the functions (sign, encrypt. certify) to be done with the
> master key).
> 
> Does matter a lot if I can't trust the subkey of someone whom I want 
> to encrypt to.

> How real is this threat, and is it any threat at all, if simply 
> binding the subkey to a different master key, won't allow for anyone 
> else other than the 'real' owner, to decrypt messages encrypted to
> that subkey?

As you correctly point out its really not that relevant for encryption
subkeys. It does have security implementations for signing subkeys; see
[cross-certification section] for some details on that.

References:
[cross-certification section]
https://gnupg.org/faq/subkey-cross-certify.html

-- 

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: PGP Key Poisoner

2019-08-13 Thread Werner Koch via Gnupg-users 
On Tue, 13 Aug 2019 09:54, gnupg-users@gnupg.org said:

> The bug, however, is in the program that chokes on poisoned keys!

Nope.  This is a long standing DoS protection by limiting the total
length of a keyblock.  The diagnostics were a bit misleading, though.

The time it took to process all these signatures during importing is due
to a fix and out of order keyblock functions which has been enabled by
default in 2.1.  It should be obvious that checking several thousands of
signatures and finding the matching user-id takes its time.

Anyway, given that these keys are real the approach with 2.2.17 is to
auto-retry an import with import-clean etc. if the keyblock size hits
the size limit.  For keyserver imports import-clean is also the default.


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: PGP Key Poisoner

2019-08-13 Thread David 
On 12/08/2019 15:47, Ralph Seichter wrote:
> * da...@gbenet.com:
> 
>> putting this code on Github whist demonstrating a point - was foolish
> 
> No, it was not. Foolish would be to pretend the conceptual flaw does not
> exist, cover your ears with your hands and go "la la la".
> 
>> To say that this was in practice and common knowledge for years - it's
>> new to me and many thousands of pgp users.
> 
> Are you suggesting that people "in the know" should let people with a
> potentially harmful lack of knowledge stay blissfully unaware? What good
> would that do?
> 
>> 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! The "Captain's B(L)og"
> 
> I think that, in light of your message, is quite a ridiculous signature.
> https://gbenet.com advertises itself as a "Capitalist Free Website For
> Free Thinkers!" stating "I have no ''beliefs'' no secret agenda's [sic] -
> other than to bring you knowledge which you may not be aware of". Well,
> some knowledge was brought to you via GitHub, so enjoy. :-)
> 
> -Ralph
> 
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 
Thank you Ralf,

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! The "Captain's B(L)og"
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: PGP Key Poisoner

2019-08-13 Thread Alessandro Vesely via Gnupg-users 
On Mon 12/Aug/2019 19:27:49 +0200 Peter Lebbing wrote:
> On 12/08/2019 18:39, Stefan Claas via Gnupg-users wrote:
>> Why was is then not fixed a decade ago, like it was done with 2.2.17?
> 
> There is no fix for the SKS keyserver network, which explains why it
> wasn't fixed in 2.2.17 either. In fact, fixes have been deployed over
> the last several years. DANE, WKD, Autocrypt, work on
> keys.openpgp.org...


This and John Z mentioning OCaml seem to point a finger in the wrong
direction.  The key poisoner shows that 20 signatures can be
handled in a few seconds (I didn't try, I trust the author).  More
than a reasonable number of signatures makes no sense in practice, so
I agree lists should somehow be "fixed" so as not to accept an
unreasonable number of signatures (reasonable == 2??)

The bug, however, is in the program that chokes on poisoned keys!

Was that fixed, yet?


Best
Ale



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

Re: PGP Key Poisoner

2019-08-12 Thread Robert J. Hansen 
> I don't want to warm-up this topic again, but... didn't Robert said in his
> github gist that the issue was known for more than a decade?

I did.  Much closer to two decades than one.  I remember talking about
it with Randy Harmon of PGP Security in 2000.

> Why was is then not fixed a decade ago, like it was done with 2.2.17?

Re-read my Gist, please.  It's all in there.

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

Re: PGP Key Poisoner

2019-08-12 Thread U'll Be King Of The Stars 



On 12 August 2019 18:27:49 BST, Peter Lebbing  wrote:
>On 12/08/2019 18:39, Stefan Claas via Gnupg-users wrote:
>> Why was is then not fixed a decade ago, like it was done with 2.2.17?
>
>There is no fix for the SKS keyserver network, which explains why it
>wasn't fixed in 2.2.17 either. In fact, fixes have been deployed over
>the last several years. DANE, WKD, Autocrypt, work on
>keys.openpgp.org...

I still contend that a large subset of the most harmful factors in all of this 
are those awful GnuPG beginners tutorials that encourage the inexperienced new 
user to upload their new keys to keyservers.

I would love to fix this problem from this perspective.  Before too long I 
would like to determine if I can schedule time to work on it.  It's an 
important thing for an important project that I just happen to be particularly 
interested in.

>I thought this (there is no fix) was pretty solidly established by now
>on this mailing list and elsewhere?

The things I missed are:

- how to check and clean a user's local keyring

- how to update the user's local configuration in ~/.gnupg

Andrew

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

Re: PGP Key Poisoner

2019-08-12 Thread Stefan Claas via Gnupg-users 
Peter Lebbing wrote:

> On 12/08/2019 18:39, Stefan Claas via Gnupg-users wrote:
> > Why was is then not fixed a decade ago, like it was done with 2.2.17?
> 
> There is no fix for the SKS keyserver network, which explains why it
> wasn't fixed in 2.2.17 either. In fact, fixes have been deployed over
> the last several years. DANE, WKD, Autocrypt, work on
> keys.openpgp.org...
> 
> I thought this (there is no fix) was pretty solidly established by now
> on this mailing list and elsewhere?
> 
> Peter.

Yes, but still I don't understand the attitude of the SKS operators.

People know there that there are issues for a decade with the software running
on their servers and they don't understand the codebase to fix issues.

And when things later happen, like recently, they still run their servers.

I wonder why those SKS key servers are so important to be still in service as
of today since we have WKD, Hagrid, keybase, Mailvelope Key Server and Facebook?

Regards
Stefan

-- 
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD)

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

Re: PGP Key Poisoner

2019-08-12 Thread John Z. 
> I don't want to warm-up this topic again, but... didn't Robert said in his
> github gist that the issue was known for more than a decade?
> 
> Why was is then not fixed a decade ago, like it was done with 2.2.17?

The link in the github document, points to another link which explains
that the code is difficult to work with, and -iirc- is written in OCaml
as a Ph.D. thesis.
I stand corrected, if I'm wrong.

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

-- 
"That gum you like is going to come back in style."

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

Re: PGP Key Poisoner

2019-08-12 Thread U'll Be King of the Stars 

On 12/08/2019 16:44, Ryan McGinnis via Gnupg-users wrote:
Yes, ironically, this proof of concept is the responsible way to 
demonstrate the issue (after a sufficient waiting period following a 
private disclosure to the developers)

I don't understand how this is irony.  I must have missed something.

Are you suggesting that because the entire community have known about 
this for a long time and did nothing, then the problem has effectively 
been disclosed already?  Therefore something should have been done long 
ago and because it wasn't exploiting the defect like this should not be 
something to complain about?


Andrew
--
OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9

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

Re: PGP Key Poisoner

2019-08-12 Thread Peter Lebbing 
On 12/08/2019 18:39, Stefan Claas via Gnupg-users wrote:
> Why was is then not fixed a decade ago, like it was done with 2.2.17?

There is no fix for the SKS keyserver network, which explains why it
wasn't fixed in 2.2.17 either. In fact, fixes have been deployed over
the last several years. DANE, WKD, Autocrypt, work on
keys.openpgp.org...

I thought this (there is no fix) was pretty solidly established by now
on this mailing list and elsewhere?

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

was Re: PGP Key Poisoner // now "Binding one person's subkey to another person's primary key"

2019-08-12 Thread vedaal via Gnupg-users 



On 8/12/2019 at 7:28 AM, "Juergen Bruckner via Gnupg-users" 
 wrote:

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

=
Here is a quote from the above site:

=[ begin quoted material ]=

As far as keyserver weaknesses go, key poisoning attacks are really just 
scratching the surface. 
For example, did you know other people can bind your subkeys to their primary 
key?

=[ end quoted material ]=

Can this really be done?

(Does not matter so much to me personally, as I grew up with v3 keys, 
and even when using a V4 key, I don't generate a subkey, 
but allow all the functions (sign, encrypt. certify) to be done with the master 
key).

Does matter a lot if I can't trust the subkey of someone whom I want to encrypt 
to.

How real is this threat, and is it any threat at all, 
if simply binding the subkey to a different master key, 
won't allow for anyone else other than the 'real' owner, to decrypt messages 
encrypted to that subkey?

TIA

vedaal


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

Re: PGP Key Poisoner

2019-08-12 Thread Stefan Claas via Gnupg-users 
Ryan McGinnis via Gnupg-users wrote:

> Yes, ironically, this proof of concept is the responsible way to demonstrate
> the issue (after a sufficient waiting period following a private disclosure
> to the developers), rather than, say, demonstrating the issue by spitefully
> poisoning the keys of a few prominent people in the GPG community.   The “if
> nobody talks about it and it remains obscure then it is not an issue” is
> something you would expect from a Mickey Mouse outfit that has no real
> understanding of security, not from a software development community that is
> essentially creating platforms focused on gold-standard security applications
> that underpin a lot of development infrastructure.  
> 
> Just my two cents *ploink ploink*

I don't want to warm-up this topic again, but... didn't Robert said in his
github gist that the issue was known for more than a decade?

Why was is then not fixed a decade ago, like it was done with 2.2.17?

Regards
Stefan
-- 
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD)

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

Re: PGP Key Poisoner

2019-08-12 Thread Stefan Claas via Gnupg-users 
Ryan McGinnis via Gnupg-users wrote:

[snip]

Not to be off-topic but I wonder why your message, when reading it
in my MUA, displays this in the message body:

Never seen this before on the ML.

c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="publicKey - r...@digicana.com -
5c738727ee58786a777c4f1db5aa3fa3486ed7ad.as= c"

LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tClZlcnNpb246IFBt
Y3J5cHRvIEdvbGFuZyAwLjAuMSAoZGRhY2ViZTApCkNvbW1lbnQ6IGh0dHBzOi8v
cHJvdG9ubWFpbC5jb20KCnhzRk5CRm95d3BvQkVBQ0dsQ0x6dUl4UHR1VDYwQld3
K1luQ0V3NS9HbFhJeDVYNmwzTkpnRGlUL1FydjZtM0MKWDROSkVIY21VT3J1SWhS
L2JJMFdrdnVXVjRSZnh2MEJLUWpwN0puTVdSRE9ZNU54SWNrdk1KR3BsTFRoY3lS
agpLcUF2aXhTcnVrc3h0M3YzQTViNzdLeXcxZXlCMytlQzNZbzBnMjh5aGhmbG4x
Z2V4enNVc3V6U1crRml4eGd6ClMyS2RKMjZhWjhTYjNnanZmSEx2L01LaFhsdVN3
WWdYSURLTWlVT2liMGlEVmRXUGZGWENwVmJIM28xOFZueFQKZEMzVUkzdlZtbEph
clI0TzV4SXA2RndkbVFWdGo3M1pNSGRnWW5RY2VHWWN3b2I4dGFPMGRLZlUrMzEv
Ymp1dQpNYU9qeTJ1S25DeDlsZWVLNEgxM0pjYkl5R1NLN2pyQWVRUk53RTU4VXpC
SlpVQnMxSURjZFlZN1l2MW9iOWlNClljZmtaaHF6enREaksxUVAzSWJlM0FHMDJY
K3JVWExjdmxoOEVjY0RiL1c1MElBK2VqRHk3eUZRYjZTSys0U3AKSXJaSEdQamYx
eUQ0eGtraHpORlBKMm1ZR040aENDcm5XckRnL2hDM3J4U3dDcEkzUEV4bFo4T0Y5
ank5alR0cQpJUngvelhTUUtnSmNBRHM0dHNOSGZ6UHJuRXk0MWJzbWNkSTBOcm5j
UGNmMjVqRnZhUFR3QkhBQ3lIbG1GWDJ6Ci9HdUNoZW9wYXhtaVZKRnVWbGVxcnR4
ZVRCTjR2NzlMaHhCR3RDVWRZSDlHcmVuRnZ6QTl2OFZNQTZyOWQ3YVcKQ2I3bDBK
SEw4d3pEQk9sRENiSk1adlQ3dER4eWwyTUl2MTFMUWVJSW5SbEk2SkJ4TENGWnVo
WVB6d0FSQVFBQgp6U1Z5ZVdGdVFHUnBaMmxqWVc1aExtTnZiU0E4Y25saGJrQmth
V2RwWTJGdVlTNWpiMjArd3NGMUJCQUJDQUFwCkJRSmFNc0tnQmdzSkJ3Z0RBZ2tR
dGFvL28waHUxNjBFRlFnS0FnTVdBZ0VDR1FFQ0d3TUNIZ0VBQUp5TEQvMFQKZUdG
YmJ1TnlQZmxUb3NkbW1LQUM2Wnl1RHdKeExqdkwzWW5IQVVQa1RPL2E2eFR0RVoy
QjQxL21PeDJPVGN5aApKaGh3dEIwL2xzU043cjVyWEh6VVc0VmU2R1NTOFBFSTNq
MUl5TS93ZWN2MytnYjM4ZmZkRkVKQTFiVW45K2YvCnV5aFFJRmFMd0ZwcThVUUd4
RFJKOTFRWGNYRnJQemFsc3Y5S0tOY3QxdFJDbGZWblFSNzdCemtoZklKczJnUWkK
eVQxbCtWRnF6WEFoVmlpdXpSZGxKTWFUTGIyMzZVa2VPeC9leU5WRWNpdlZZb3V5
MkJ6TC9kVzI4V0RQUHRkVgpIT2NWbVY0S2ZhWUpwSDRtQkhCL0tQK0pOUXk1c3BW
Zk1MTWZDMDhyNWEwRUZFM0J5ZWJsdDNPTlBtKzJ5bXpDClJvdEl0ejhUN3Njd3U0
eFRtSXc1V1dSY0lpM21iRFcvbWVmbzd3aGJYM283TmlkUEJDK1pxSnNxTG9Obm8v
YUQKUFlYbnBUekFiczRVVFNxcDZQNDlNSFZXTkY0L24vYVhVM1ZoQnZaeDBoMU5O
TmJPMVB6Ui84U3I3ZmVkRDlVQwpuaUpOSmdmYUtodDFpMTlQYytCRjUrc2duYlJa
ZUlmU3hIV2ZYRCtrcklXR1ptUkJhQnBHelIzSnIzQUF3Q2NECnVKVmVDWHhJZTE3
WlRIeXdxVlpsb1hGWEVSSkJUZm1KK0FEbjIrc0ZNanBkV0Jhd3NsNXhYLzlmZmlP
WWY4aTAKbEdoNnZraWtCbkdaem5YSVp4Y3YvSVZpSHVnYlY3M3FwdktUaVpiME5o
WDlhd3kybGJqcWRxZzR4UHhuMlJJbwpwaEY5VTNpYmxhcDRqSnJZMFo2NmdNUEhB
b2VVWlVJa1crWjYzT1BJbE03QlRRUmFNc0thQVJBQWlSblptNHVjClBLc0ZEUG5N
SjVWcUVkeE9LcVRhbGsxRDM3NzEyemovWjcwNjlaRkV6QnY5UkVUcU9qdmFCQ1ZU
dExrWmpVS3UKQXQ5QVF3S0prcUhNbXpHVGdsVGt5cThEM0Z3cDExeVVoQm12M3lP
ciswVjVNZUU2OUhNdXFpdHBPNWdYbW9NMQoyQ1VBUERzcWV0OEY4THN0RUpNYlJo
cHh2T3NnbU1SV2dGbTVMNzRjeXFPVDQ0K01vOCt1THdldlBIMXBDN2JFCi9rTEVQ
ZXdjQUUvNjBwUTBZZ1ZQMkxlNngyaHQ4Q3pEWjdwOGNTSGtYbEJhOXlIa1haUkV0
VStMMFdJSU0rM28KRjBycnhMeENpcmJjU2hOM1pFeHgra0xuTTJ6YjN4bUVRd1k2
YndsVXRIa25ub1ZwSmtaWFBjM21OSlFLYzA4NAorWEdnSWNQYXEwNTN2cElaa093
ZlFib292azZ4cG9sWkdmU254c1FTVnNCTFQ3WFlKR2UydjRTdExuS1UzRzFXCk1J
aHk4TitzK1ArUHRPYytZRU9sNS82cmhiZUk2UkFsS21wcisvMGhFWG9lK0Z4USt0
Njc5TS9kR2ptRmM1YlIKVFl0b1k2YlpuaGpHYnZ0dWY0K3pmUFNudmFMOFFtd2Rj
bjZYSFExVndCQmFVWXlqYUxJTCtOam1LSjdSWGhrawoyeUs0SU1iZDVYMFl1TDVm
dVpnTXE5OUJTbkVtZ1B0QUhwQW9rci9sWXV0VW82NmhIUEQ5OWlBSUwxYUI5aU5l
CmpqU0FjdWI1QThQMENaYWJNTWVsdmw5QnRXRGVHZ0d6K3lFQmlJN09MOHdaOUxn
NjM0RTZRNjVIUmZBcUFiU2cKc0pyRmRHc0tKM3NuUXRhbGJ6UzJBaldVUnZWOW5T
aHpuV3NBRVFFQUFjTEJYd1FZQVFnQUV3VUNXakxDb3drUQp0YW8vbzBodTE2MENH
d3dBQU5qSkQvNDFRTmpkSkQ3VzNZR0RkRjd6SXlOMW5FME9WTElsaGh5WHZ4Mk5C
UzlFCjhPMzM4V1dpbnMzekxJZTdCenFyNkhTSmdQZUxyRElJWi8rQ29aSW9aZm52
cEI2bllsbWdQME8zdUZuSnNQYysKTjVnc1E0cDEzZEF4QldWMVNBSmJtMDdyZ3VT
RVMzNzlpdHdPTWFuSU9KTVNQTnhETHI4YUxLY2pKV0tqNWRnTgpvMEx1eWFYSjdI
OU02MWMrMytUV25ZdWNBakZDQ2s3STcrRldtWHZ2OEgzVHBBeEF6K3FPYllKRDRS
UDFaL3RSCjdtYVJyQU5NalVZY0lneVR2RzlsNDF2ZG1jR01lZDN4bTc3VS9Yek96
ZlVDbEVEbWFLMzlibU9HNEF1YzVSOHkKNjIrMkhJSS94cmE5V2VlaUlPZXNxTUVN
NTB5NkFjUUVSVnAydDQyZjFucld5aU1KMkR6cVMyUlZwMHZiNWNsRApIK25XUUlM
bGxuN1VBd09ONHJvaXpQZm5zeTRBOGdiTS9KcXlMazA1Vnl4WlEzWUNUZUJJcVJm
anUyUndIM0l2CjRuZFBhaXBIUkY3R3dOZEdKWDJFYmJ4L1hyMHBLbUx3K0tKa211
ZEVuU0VqYUJTeFYwcml1N3dHUHZ6UVFhL3AKWTIrNmlzWDgxeVNibFlqakVwVCsz
eDUvdmFzMDcxL3dNdlFaWmJrc29RT3dvZGxZSHFHellGOTlXbFoyMHJySgpnL1F4
R2VQS2xRU01jQWlYalhXUzI4bkYxY2xVZHRlUlNXM0JDbHJsbGcyNFlNNWRZL1ZC
RDhzZWp5aERNVUI4CnA3NUNCa1JDTzZ4UlozcnJ5QXBqQTM0QnJlNnd0NlJOT1A5
V1VTYzFnbmhPaUk5K3E1a3oxc0JHWm9VRXRNTmsKZ1E9PQo9SXZXYQotLS0tLUVO
RCBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0t

[signature.asc  application/pgp-signature (839 Bytes)]

Regards
Stefan 

-- 
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD)

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

Re: PGP Key Poisoner

2019-08-12 Thread Ryan McGinnis via Gnupg-users 
Yes, ironically, this proof of concept is the responsible way to demonstrate the issue (after a sufficient waiting period following a private disclosure to the developers), rather than, say, demonstrating the issue by spitefully poisoning the keys of a few prominent people in the GPG community.   The “if nobody talks about it and it remains obscure then it is not an issue” is something you would expect from a Mickey Mouse outfit that has no real understanding of security, not from a software development community that is essentially creating platforms focused on gold-standard security applications that underpin a lot of development infrastructure.  Just my two cents *ploink ploink*-Ryan McGinnishttps://bigstormpicture.com https://keybase.io/digicanaSent via ProtonMail  On Mon, Aug 12, 2019 at 09:54, Stefan Claas  wrote:  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 GitHubAFAIK it is common pratice to publish PoCs to help program authors to improveor quickly fix their open source security software. Otherwise long standingissues may have been never fixed.RegardsStefan--box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD)___Gnupg-users mailing listGnupg-users@gnupg.orghttp://lists.gnupg.org/mailman/listinfo/gnupg-users


c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="publicKey - r...@digicana.com - 
5c738727ee58786a777c4f1db5aa3fa3486ed7ad.as=
c"

LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tClZlcnNpb246IFBt
Y3J5cHRvIEdvbGFuZyAwLjAuMSAoZGRhY2ViZTApCkNvbW1lbnQ6IGh0dHBzOi8v
cHJvdG9ubWFpbC5jb20KCnhzRk5CRm95d3BvQkVBQ0dsQ0x6dUl4UHR1VDYwQld3
K1luQ0V3NS9HbFhJeDVYNmwzTkpnRGlUL1FydjZtM0MKWDROSkVIY21VT3J1SWhS
L2JJMFdrdnVXVjRSZnh2MEJLUWpwN0puTVdSRE9ZNU54SWNrdk1KR3BsTFRoY3lS
agpLcUF2aXhTcnVrc3h0M3YzQTViNzdLeXcxZXlCMytlQzNZbzBnMjh5aGhmbG4x
Z2V4enNVc3V6U1crRml4eGd6ClMyS2RKMjZhWjhTYjNnanZmSEx2L01LaFhsdVN3
WWdYSURLTWlVT2liMGlEVmRXUGZGWENwVmJIM28xOFZueFQKZEMzVUkzdlZtbEph
clI0TzV4SXA2RndkbVFWdGo3M1pNSGRnWW5RY2VHWWN3b2I4dGFPMGRLZlUrMzEv
Ymp1dQpNYU9qeTJ1S25DeDlsZWVLNEgxM0pjYkl5R1NLN2pyQWVRUk53RTU4VXpC
SlpVQnMxSURjZFlZN1l2MW9iOWlNClljZmtaaHF6enREaksxUVAzSWJlM0FHMDJY
K3JVWExjdmxoOEVjY0RiL1c1MElBK2VqRHk3eUZRYjZTSys0U3AKSXJaSEdQamYx
eUQ0eGtraHpORlBKMm1ZR040aENDcm5XckRnL2hDM3J4U3dDcEkzUEV4bFo4T0Y5
ank5alR0cQpJUngvelhTUUtnSmNBRHM0dHNOSGZ6UHJuRXk0MWJzbWNkSTBOcm5j
UGNmMjVqRnZhUFR3QkhBQ3lIbG1GWDJ6Ci9HdUNoZW9wYXhtaVZKRnVWbGVxcnR4
ZVRCTjR2NzlMaHhCR3RDVWRZSDlHcmVuRnZ6QTl2OFZNQTZyOWQ3YVcKQ2I3bDBK
SEw4d3pEQk9sRENiSk1adlQ3dER4eWwyTUl2MTFMUWVJSW5SbEk2SkJ4TENGWnVo
WVB6d0FSQVFBQgp6U1Z5ZVdGdVFHUnBaMmxqWVc1aExtTnZiU0E4Y25saGJrQmth
V2RwWTJGdVlTNWpiMjArd3NGMUJCQUJDQUFwCkJRSmFNc0tnQmdzSkJ3Z0RBZ2tR
dGFvL28waHUxNjBFRlFnS0FnTVdBZ0VDR1FFQ0d3TUNIZ0VBQUp5TEQvMFQKZUdG
YmJ1TnlQZmxUb3NkbW1LQUM2Wnl1RHdKeExqdkwzWW5IQVVQa1RPL2E2eFR0RVoy
QjQxL21PeDJPVGN5aApKaGh3dEIwL2xzU043cjVyWEh6VVc0VmU2R1NTOFBFSTNq
MUl5TS93ZWN2MytnYjM4ZmZkRkVKQTFiVW45K2YvCnV5aFFJRmFMd0ZwcThVUUd4
RFJKOTFRWGNYRnJQemFsc3Y5S0tOY3QxdFJDbGZWblFSNzdCemtoZklKczJnUWkK
eVQxbCtWRnF6WEFoVmlpdXpSZGxKTWFUTGIyMzZVa2VPeC9leU5WRWNpdlZZb3V5
MkJ6TC9kVzI4V0RQUHRkVgpIT2NWbVY0S2ZhWUpwSDRtQkhCL0tQK0pOUXk1c3BW
Zk1MTWZDMDhyNWEwRUZFM0J5ZWJsdDNPTlBtKzJ5bXpDClJvdEl0ejhUN3Njd3U0
eFRtSXc1V1dSY0lpM21iRFcvbWVmbzd3aGJYM283TmlkUEJDK1pxSnNxTG9Obm8v
YUQKUFlYbnBUekFiczRVVFNxcDZQNDlNSFZXTkY0L24vYVhVM1ZoQnZaeDBoMU5O
TmJPMVB6Ui84U3I3ZmVkRDlVQwpuaUpOSmdmYUtodDFpMTlQYytCRjUrc2duYlJa
ZUlmU3hIV2ZYRCtrcklXR1ptUkJhQnBHelIzSnIzQUF3Q2NECnVKVmVDWHhJZTE3
WlRIeXdxVlpsb1hGWEVSSkJUZm1KK0FEbjIrc0ZNanBkV0Jhd3NsNXhYLzlmZmlP
WWY4aTAKbEdoNnZraWtCbkdaem5YSVp4Y3YvSVZpSHVnYlY3M3FwdktUaVpiME5o
WDlhd3kybGJqcWRxZzR4UHhuMlJJbwpwaEY5VTNpYmxhcDRqSnJZMFo2NmdNUEhB
b2VVWlVJa1crWjYzT1BJbE03QlRRUmFNc0thQVJBQWlSblptNHVjClBLc0ZEUG5N
SjVWcUVkeE9LcVRhbGsxRDM3NzEyemovWjcwNjlaRkV6QnY5UkVUcU9qdmFCQ1ZU
dExrWmpVS3UKQXQ5QVF3S0prcUhNbXpHVGdsVGt5cThEM0Z3cDExeVVoQm12M3lP
ciswVjVNZUU2OUhNdXFpdHBPNWdYbW9NMQoyQ1VBUERzcWV0OEY4THN0RUpNYlJo
cHh2T3NnbU1SV2dGbTVMNzRjeXFPVDQ0K01vOCt1THdldlBIMXBDN2JFCi9rTEVQ
ZXdjQUUvNjBwUTBZZ1ZQMkxlNngyaHQ4Q3pEWjdwOGNTSGtYbEJhOXlIa1haUkV0
VStMMFdJSU0rM28KRjBycnhMeENpcmJjU2hOM1pFeHgra0xuTTJ6YjN4bUVRd1k2
YndsVXRIa25ub1ZwSmtaWFBjM21OSlFLYzA4NAorWEdnSWNQYXEwNTN2cElaa093
ZlFib292azZ4cG9sWkdmU254c1FTVnNCTFQ3WFlKR2UydjRTdExuS1UzRzFXCk1J
aHk4TitzK1ArUHRPYytZRU9sNS82cmhiZUk2UkFsS21wcisvMGhFWG9lK0Z4USt0
Njc5TS9kR2ptRmM1YlIKVFl0b1k2YlpuaGpHYnZ0dWY0K3pmUFNudmFMOFFtd2Rj
bjZYSFExVndCQmFVWXlqYUxJTCtOam1LSjdSWGhrawoyeUs0SU1iZDVYMFl1TDVm
dVpnTXE5OUJTbkVtZ1B0QUhwQW9rci9sWXV0VW82NmhIUEQ5OWlBSUwxYUI5aU5l
CmpqU0FjdWI1QThQMENaYWJNTWVsdmw5QnRXRGVHZ0d6K3lFQmlJN09MOHdaOUxn
NjM0RTZRNjVIUmZBcUFiU2cKc0pyRmRHc0tKM3NuUXRhbGJ6UzJBaldVUnZWOW5T
aHpuV3NBRVFFQUFjTEJYd1FZQVFnQUV3VUNXakxDb3drUQp0YW8vbzBodTE2MENH

Re: PGP Key Poisoner

2019-08-12 Thread Stefan Claas 
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

AFAIK it is common pratice to publish PoCs to help program authors to improve
or quickly fix their open source security software. Otherwise long standing
issues may have been never fixed.

Regards
Stefan

-- 
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD)

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

Re: PGP Key Poisoner

2019-08-12 Thread Ralph Seichter 
* da...@gbenet.com:

> putting this code on Github whist demonstrating a point - was foolish

No, it was not. Foolish would be to pretend the conceptual flaw does not
exist, cover your ears with your hands and go "la la la".

> To say that this was in practice and common knowledge for years - it's
> new to me and many thousands of pgp users.

Are you suggesting that people "in the know" should let people with a
potentially harmful lack of knowledge stay blissfully unaware? What good
would that do?

> 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! The "Captain's B(L)og"

I think that, in light of your message, is quite a ridiculous signature.
https://gbenet.com advertises itself as a "Capitalist Free Website For
Free Thinkers!" stating "I have no ''beliefs'' no secret agenda's [sic] -
other than to bring you knowledge which you may not be aware of". Well,
some knowledge was brought to you via GitHub, so enjoy. :-)

-Ralph

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

Re: PGP Key Poisoner

2019-08-12 Thread Mauricio Tavares via Gnupg-users 
On Mon, Aug 12, 2019 at 8:10 AM David  wrote:
>
> On 12/08/2019 12:25, 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
> >
> > regards
> > Juergen
> >
> > Am 11.08.19 um 23:47 schrieb Anonymous Remailer (austria):
> >>
> >> https://github.com/skeeto/pgp-poisoner
> >>
> >> ___
> >> Gnupg-users mailing list
> >> Gnupg-users@gnupg.org
> >> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> >>
> >
> >
> > ___
> > Gnupg-users mailing list
> > Gnupg-users@gnupg.org
> > http://lists.gnupg.org/mailman/listinfo/gnupg-users
> >
> To be frank - putting this code on Github whist demonstrating a point -
> was foolish - it put's the code out into the wild - and some silly smart
> arse is going to play.
>
> It also begs the question - who did the attacks on SKS keyservers? "I
> have katana and I just wanted to demonstrate cutting people's head's of
> because I can." But am not going to accept the responsibility and be
> accountable for my actions. Such a position is untenable in Law and in
> ethics.
>
> There are hundreds of thousands of people globally who are employed paid
> by their respective intelligence agencies to write malicious code. They
> hide behind the fact that they are paid - it's just a day-time 9 to 5
> job - and have no sense of responsibility or accountability working in
> contravention of their own countries laws.
>
> Now you have put the code into the public domain - to prove a point? The
> justification and points hardly support an ethical just standpoint. To
> say that this was in practice and common knowledge for years - it's new
> to me and many thousands of pgp users. Many thousands of people got
> infected - and had no thought to back up their king rings and have to
> start all over again.
>
  I take you are against CVE lists.


> Just because one can develop a nuclear bomb - it proves real stupidity
> to drop it on an unsuspecting public.
>
> Be Happy!
>
> 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! The "Captain's B(L)og"
> https://gbenet.com
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

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

Re: PGP Key Poisoner

2019-08-12 Thread Vincent Breitmoser via Gnupg-users 


> To be frank - putting this code on Github whist demonstrating a point -
> was foolish

No it's not. It is the basis of cryptograhpy.
See also: https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle

> Now you have put the code into the public domain - to prove a point?

Yes. And that point is that some of our security was built on obscurity.
See also: https://en.wikipedia.org/wiki/Shooting_the_messenger

 - V


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

Re: PGP Key Poisoner

2019-08-12 Thread David 
On 12/08/2019 12:25, 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
> 
> regards
> Juergen
> 
> Am 11.08.19 um 23:47 schrieb Anonymous Remailer (austria):
>>
>> https://github.com/skeeto/pgp-poisoner
>>
>> ___
>> Gnupg-users mailing list
>> Gnupg-users@gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>>
> 
> 
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 
To be frank - putting this code on Github whist demonstrating a point -
was foolish - it put's the code out into the wild - and some silly smart
arse is going to play.

It also begs the question - who did the attacks on SKS keyservers? "I
have katana and I just wanted to demonstrate cutting people's head's of
because I can." But am not going to accept the responsibility and be
accountable for my actions. Such a position is untenable in Law and in
ethics.

There are hundreds of thousands of people globally who are employed paid
by their respective intelligence agencies to write malicious code. They
hide behind the fact that they are paid - it's just a day-time 9 to 5
job - and have no sense of responsibility or accountability working in
contravention of their own countries laws.

Now you have put the code into the public domain - to prove a point? The
justification and points hardly support an ethical just standpoint. To
say that this was in practice and common knowledge for years - it's new
to me and many thousands of pgp users. Many thousands of people got
infected - and had no thought to back up their king rings and have to
start all over again.

Just because one can develop a nuclear bomb - it proves real stupidity
to drop it on an unsuspecting public.

Be Happy!

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! The "Captain's B(L)og"
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: 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