> 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
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 mo
-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 su
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
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-certific
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 ab
> 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
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 rea
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 t
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 wa
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
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
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 the
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 th
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 fa
> 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
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
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 ove
> 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 cod
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 somethi
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,
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
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
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...@digican
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. T
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 im
* 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
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 GitH
> 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 t
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 schr
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
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
32 matches
Mail list logo
