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

[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: Difficulty of fixing reconciliation

[Stefan Claas via Gnupg-users]

Robert J. Hansen wrote:

> > Good write-up. Now I have a question, in hope that SKS operators are
> > reading this too. I have learned from Robert's gist that the max. is
> > 150.000 sigs per key the servers can handle, if I am not mistaken.
> 
> I didn't say this.
> 
> I said they handle up to about that, *because we've seen keys with that
> many*.  So clearly, obviously, they handle that many.
> 
> A great many people have assumed I intended to say "and it won't handle
> more than 150,000".  Which I didn't say and don't intend.  It very well
> could handle more.

Ah, o.k. sorry, my misunderstanding!

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

[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

[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: Difficulty of fixing reconciliation

[Robert J. Hansen]

> Good write-up. Now I have a question, in hope that SKS operators are
> reading this too. I have learned from Robert's gist that the max. is
> 150.000 sigs per key the servers can handle, if I am not mistaken.

I didn't say this.

I said they handle up to about that, *because we've seen keys with that
many*.  So clearly, obviously, they handle that many.

A great many people have assumed I intended to say "and it won't handle
more than 150,000".  Which I didn't say and don't intend.  It very well
could handle more.

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

Re: PGP Key Poisoner

[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: Difficulty of fixing reconciliation

[Stefan Claas via Gnupg-users]

Peter Lebbing wrote:

[snip]

> Furthermore, the end goal is for all hosts to have the same dataset, so
> let's define progress as that the hosts become more and more alike: when
> the number of differences between the hosts has reduced, we have made
> progress. Once completed, it has progressed to the point where the
> number of differences is zero. As an aside, it has to be proven that we
> eventually progress to that point where they are the same, otherwise
> there could be a dataset that just keeps spinning, running the algorithm
> endlessly. In fact, it's well possible that this is where the
> monotonicity requirement plays a role.

[snip]

Good write-up. Now I have a question, in hope that SKS operators are
reading this too. I have learned from Robert's gist that the max. is
150.000 sigs per key the servers can handle, if I am not mistaken.

How do they handle the following:

Bob uploads his key from a key signing party with 100 sigs to server
A. Mallory and Eve attended the key signing party too and signed Bob's
key. Mallory uploads Bob's key with an additional 100k sigs on server B
and Eve does the same with server C.

Lets assume that server B and C syncs before A. What does server
B accepts then from C and vice versa, because of the 150k sig limit?

Will at the end server A, B and C have different key sets from Bob,
because of the 150k limit?

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"

[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

[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

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

[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

Difficulty of fixing reconciliation

[Peter Lebbing]

On 13/08/2019 09:54, Alessandro Vesely via Gnupg-users wrote:
> 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??)

Others tell us: the synchronization protocol as it is cannot be fixed.
You reply: I agree it should - somehow - be fixed?

The sort and unhelpful answer of course is: read the first sentence
again, or disprove it mathematically just like the algorithm was
mathematically proven to work in the first place.

But I'll try to sketch it. I don't know the synchronization protocol.
What I do know: the design goals included resistance to oppressive
regimes interested in deleting anything from the network, so it was to
be designed so it was technically impossible to delete anything.

Furthermore, this is from memory, but when I read basic information
about the SKS reconciliation algorithm, I see the terms "monotonicity
requirement for progress" or something alike.

I don't know if this is how it works, but this is how it could work:

Somebody has worked years on an algorithm for their PhD thesis which
fulfills an important task, and through those years a lot of
mathematical proofs have been spent on proving that it does what was
asked of it. One of these demands was that it could provably never
delete data that had been available earlier.

In order to make this algorithm, the PhD student discovered that they
needed to have some properties hold at *every* single step: otherwise
they could not prove that the algorithm was correct.

So let's see a single step in the reconciliation process as the
reconciliation of a single piece of data that has been added to the
network. The PhD student found they needed a requirement they called the
monotonicity requirement. I don't know what it means precisely in this
case, but I can take a guess: if two hosts are reconciling, the
monotonicity requirement could mean that the data at either one of these
hosts

- gets data added and everything that was there stays
- the data it has stays exactly the same

Those are the only two cases that satisfy the monotonicity requirement.

Furthermore, the end goal is for all hosts to have the same dataset, so
let's define progress as that the hosts become more and more alike: when
the number of differences between the hosts has reduced, we have made
progress. Once completed, it has progressed to the point where the
number of differences is zero. As an aside, it has to be proven that we
eventually progress to that point where they are the same, otherwise
there could be a dataset that just keeps spinning, running the algorithm
endlessly. In fact, it's well possible that this is where the
monotonicity requirement plays a role.

Let's do this with your max 2.

Somebody uses SKS keyserver network host A to add two signatures, call
them A1 and A2 to the key in question, which did not have any signatures
yet. Host A accepts them, they fall within the limits.

Either this same person or someone else adds two signatures on SKS
server B on the same key, call them B1 and B2. Hosts A and B haven't
reconciled yet, so B sees no signatures on the key and accepts.

Now they reconcile.

They compare their datasets. They are not the same: we still need to
have progress to get to completion. Let's reconcile signature A1. Server
A offers server B signature A1. Wait a minute, the key already has
signatures B1 and B2. Server B cannot accept signature A1, it would
break the contract that there are ever only 2 signatures on the key.

Now we have a deadlock. There is no following step that would fulfill
the monotonicity requirement as well as make any progress. The only way
to fulfill the monotonicity requirement is when server A keeps the
signatures A1 and A2, and server B keeps B1 and B2. But the progression
has halted and the process never finishes.

Ah, you say, why don't you /swap/ B1 for A1? Well, there is no such
thing as swapping. Swapping is simply the deleting of B1 followed by the
addition of A1. And monotonicity says we can't delete anything.

Besides, any limit on the number of signatures is a Denial-of-Service.
In your case, if Alice, Bob and Carol all sign eachother's keys, there's
no more room for other signatures. And if Mallory creates two bogus keys
and signs all the keys of Alice, Bob and Carol, the three can't add any
real signatures anymore.

The algorithm is designed to withstand very well funded actors,
oppressive regimes were what the designers were thinking of. Obviously,
the algorithm does this regardless of who is trying to do something
otherwise, no matter whether it is a repressive regime or the legitimate
operators and designers of the system.

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

It seems to me there is (almost?) always a denial of service. Offline
systems have more trouble with this than online systems, and even
websites (online systems) have really 

Re: PGP Key Poisoner

[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

[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

[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