Re: Difficulty of fixing reconciliation

[Jason Harris via Gnupg-users]

> On Aug 14, 2019, at 6:32 PM, MFPA via Gnupg-users  
> wrote:

> On Wednesday 14 August 2019 at 10:39:56 AM, in
> , Alessandro Vesely
> via Gnupg-users wrote:-
> 
>> I'm no expert, but it seems to me that 3rd party
>> signatures should not
>> be allowed.
> 
> Perhaps a "keyserver no-third-party-signatures" option would resolve
> this. Unlike "keyserver no-modify", honouring it would not require a
> keyserver to undertake any cryptographic checking.

No, then the “attack” just changes to making the issuing keyid = the keyid 
being attacked, so everything looks like a selfsig...

But at least then we will want to add cryptography to see which selfsigs are 
truly legitimate, right?

Sent from my iPad




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

Re: looking for assistance tracking down why i don't have the ability to run gpg from the command line

[David]

On 14/08/2019 16:30, charlie derr wrote:
> I'm running debian 10 buster (upgraded recently from stretch if that
> matters) and i use KDE. I haven't yet tried to logout of my desktop
> environment completely (and just use a native console), but I thought
> I would see if any of you had any ideas. Here's the problem:
> 
> ni@quark:~/.ssh$ gpg --list-keys
> gpg: checking the trustdb
> gpg: waiting for lock (held by 22009) ...
> gpg: waiting for lock (held by 22009) ...
> gpg: waiting for lock (held by 22009) ...
> ^C
> gpg: signal Interrupt caught ... exiting
> 
> ni@quark:~/.ssh$ ps aux | grep 22009
> ni7740  0.0  0.0   6076   892 pts/6S+   11:21   0:00 grep
> 22009
> ni   22009  2.0  0.2  89404 78536 ?RL   02:51  10:30 gpg
> --batch --no-sk-comments --status-fd 104 --no-tty --charset utf8
> --enable-progress-filter --exit-on-status-write-error --display :0
> --logger-fd 108 --with-colons --list-keys --
> 4E2247974AA5A23A5C92BB4DBB8B3D7331A9367F
> ni@quark:~/.ssh$ kill 22009
> ni@quark:~/.ssh$ gpg --list-keys
> gpg: checking the trustdb
> gpg: waiting for lock (held by 28999) ...
> gpg: waiting for lock (held by 28999) ...
> gpg: waiting for lock (held by 28999) ...
> 
> as you can see, killing the offending process doesn't work (as it
> respawns immediately)
> 
> The reason this is important to me right now is because I have a new
> laptop and I'm trying to transfer my keys to it. I have an email from
> this list sent by Robert J. Hansen on 9/14/2016 that has excellent
> instructions (which I've used in the past for this purpose) but the
> 1st command in those instructions:
> 
> gpg --armor --export
> 
> dumps a lot of output to the command line but never "finishes" (and my
> guess is that it's the same lock that's preventing that command from
> completing).
> 
>   thanks so very much in advance for your time,
>  ~c
> 
> 
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 

Hello Charlie,

On Debian 10 busty - which I have now - you have "root" I simply log
into root open the home folder go to user name folder  list hidden files
- then select the .gpg folder and copy that to a USB. You can do a
weekly backup to USB.

Then you can add it to whatever you want - but be in root to change the
ownership to whatever the users called.

when I do a --list-users t lists all my 186 keys :)

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

Key poisoning

[Daniel Clery]

If the keyserver implemented a signer blacklist, (which would scrub the
blacklisted signature from any current or incoming public keys), what
consequences am I missing?

In essence, shadowbanning a signing key. Keyservers without blacklist
support would still pass around the toxic keys, but only until they get
updated with the blacklist.

The notion of nothing getting deleted is a feature (as nice as it would be
to be able to nuke my keys from the 90s that never really got used to begin
with). Masking out signatures from bad actors seems like a valid solution.

It doesn't address all of the problems were seeing now (core infrastructure
not in a maintainable state for the project, using effectively voodoo to do
its job)

But could be a start.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Difficulty of fixing reconciliation

[MFPA via Gnupg-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Wednesday 14 August 2019 at 10:39:56 AM, in
, Alessandro Vesely
via Gnupg-users wrote:-

> I'm no expert, but it seems to me that 3rd party
> signatures should not
> be allowed.

Perhaps a "keyserver no-third-party-signatures" option would resolve
this. Unlike "keyserver no-modify", honouring it would not require a
keyserver to undertake any cryptographic checking.



- --
Best regards

MFPA  

However beautiful the strategy, you should occasionally look at the results.
-BEGIN PGP SIGNATURE-

iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCXVSMAV8UgAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw
Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju
+oVAAP9lSV1dK1iQWIkm2edvSzRwSPSY0tDflMtQmNQ65gYRNgEAzVtumEK+Ju9k
jHPNSTkkVQRm7s20GHOZOn1ZLgPASwCJApMEAQEKAH0WIQRSX6konxd5jbM7JygT
DfUWES/A/wUCXVSMAV8UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw
REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/28RD/4wRqb6Pt+We48Ahvk+L5191X5M
DrjPHAq3hLombNaUTmXpRAb8Eg8cBebyPKMxUd2vjFWPKMBFGzhJY6YvpFoOa7aP
huLsdyVMVn1TWJKGO15Q8yV6fc5nS6DLhfNjAytGad2jh9NjksHUh7j4xEyfBlFU
C9BkhudbBLWwk+CqS/rw3LioT2g9JiYshq2U/HIh6NOzRtdelIfJCXI9S8vKmiYJ
cvrL1TcBolntx3afmK5UdnUY+oLc64/Gh1pyuYixuCY829fhsE4mwPdgOzqhf/Ua
k/o+RmUHE4xxCVrqJFNNknKAklgUjr5lWSPHvFfRrTJ+QKAxvdAeuNExSvub9Kg4
YUv4Khv4s4otrRFSRqhahnqciEehbK98x4L02/6sU2Agiork8ScyESaAI4RTy1GR
QuHDPbdqYaI27ocek5VIgadjO3cjtOh8frlR94xOujcJTZk9DRLPGeBiKdlcHUFe
zjCoM/ttbJWjGkoxm80/2ENiFvOeOqi7Bcdm0h+9ftpdMh2n2g89OOoXuOgljkKy
4NddgVAF2UBOZ3/fBu0tawhZdrnTcTcAsWCjPQ0hK7xb8wu8Xo640O5uRJZ+BEWn
Cyi0JHc/FF4qIiI3GSV2WWbOEWxW7QDj/Fb2NgtwKyZbA1FOt59EzNFYMFxaFznC
gHi1vm0nVDGGPqjvcA==
=ChAv
-END PGP SIGNATURE-


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

Re: Difficulty of fixing reconciliation

[Werner Koch via Gnupg-users]

On Wed, 14 Aug 2019 15:45, r...@sixdemonbag.org said:

> developed *more than twenty years ago* it was decided to support
> arbitrary numbers of third-party signatures.  GnuPG faithfully

At least OpenPGP has this:

  5.2.3.17.  Key Server Preferences

   (N octets of flags)

   This is a list of one-bit flags that indicate preferences that the
   key holder has about how the key is handled on a key server.  All
   undefined flags MUST be zero.

   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.

GnuPG has always set this flag in anticipation that the keyservers will
eventually come up with an authenticated upload method.  As we all know
the keyserver developers didn't considered that as a priority thing and
thus we are at the state we are know.

At the first and only keyserver conference in 2000 this topic had been
on the agenda.  Due to the burst of the dotcom bubble we never got
together again and most thought that SKS was the way to go.  Recall that
it solved the problem with OpenPGP (HKP supported only 1 primary plus
one subkey) and the performance problem.

Since December 2013 it was pretty clear that the WoT and the keyservers
will have scaling problems.


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

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

[Robert J. Hansen]

> Can you give me a valid reason why anyone would want their key signed by
> 150,000 people or more?? How can you meet 150,000 people?

Sure, if you can give me a valid reason why I *should* give you a valid
reason.

Seriously.

I'm not a GnuPG developer.  I don't run an SKS keyserver.  I know a good
bit about the internals of both, but I wasn't involved in the decisions
and I'm getting really annoyed at people who expect me to be an
apologist just because they mistakenly think I'm more involved than I am.

Now that I've got that out of the way, welcome to the Zero-One-N rule.
It's a rule of thumb in software engineering that says to either allow
none of something, only one of something, or an arbitrary number of
somethings.  Either support no third-party signatures, one third-party
signature, or arbitrary numbers of them.  When the OpenPGP spec was
developed *more than twenty years ago* it was decided to support
arbitrary numbers of third-party signatures.  GnuPG faithfully
implements this spec, even though this policy has turned out to not be a
good idea.

If you want to be *productive*, get over on the IETF Working Group
mailing list and start asking how the next draft of the spec is going to
resolve this problem.  That's where the problem began.  That's where you
need to solve it.

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

Re: PGP Key Poisoner

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

[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

looking for assistance tracking down why i don't have the ability to run gpg from the command line

[charlie derr]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I'm running debian 10 buster (upgraded recently from stretch if that
matters) and i use KDE. I haven't yet tried to logout of my desktop
environment completely (and just use a native console), but I thought
I would see if any of you had any ideas. Here's the problem:

ni@quark:~/.ssh$ gpg --list-keys
gpg: checking the trustdb
gpg: waiting for lock (held by 22009) ...
gpg: waiting for lock (held by 22009) ...
gpg: waiting for lock (held by 22009) ...
^C
gpg: signal Interrupt caught ... exiting

ni@quark:~/.ssh$ ps aux | grep 22009
ni7740  0.0  0.0   6076   892 pts/6S+   11:21   0:00 grep
22009
ni   22009  2.0  0.2  89404 78536 ?RL   02:51  10:30 gpg
- --batch --no-sk-comments --status-fd 104 --no-tty --charset utf8
- --enable-progress-filter --exit-on-status-write-error --display :0
- --logger-fd 108 --with-colons --list-keys --
4E2247974AA5A23A5C92BB4DBB8B3D7331A9367F
ni@quark:~/.ssh$ kill 22009
ni@quark:~/.ssh$ gpg --list-keys
gpg: checking the trustdb
gpg: waiting for lock (held by 28999) ...
gpg: waiting for lock (held by 28999) ...
gpg: waiting for lock (held by 28999) ...

as you can see, killing the offending process doesn't work (as it
respawns immediately)

The reason this is important to me right now is because I have a new
laptop and I'm trying to transfer my keys to it. I have an email from
this list sent by Robert J. Hansen on 9/14/2016 that has excellent
instructions (which I've used in the past for this purpose) but the
1st command in those instructions:

gpg --armor --export

dumps a lot of output to the command line but never "finishes" (and my
guess is that it's the same lock that's preventing that command from
completing).

  thanks so very much in advance for your time,
 ~c

- -- 
Charlie Derr   Director, Instructional Technology 413-528-7344
https://www.simons-rock.edu Bard College at Simon's Rock
Encryption key: http://hope.simons-rock.edu/~cderr/
Personal writing: https://medium.com/@cderr   Pronouns: he or they
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEETiJHl0qlojpckrtNu4s9czGpNn8FAl1UKR4ACgkQu4s9czGp
Nn93/w/+MX6xS0bMETgq/dWUaIt8vzubE1z9HypapZDyxqFyObsoWJS0AEwLMmwx
VqEAxFgbGrWT18CP04dLP1L6KPqAI5FsPm9ge0uXYVYF8M5xluIy8NALGWSbwhTm
NZlAuPwnzMmNaR4jD2iVF5PuIzzQF8Cx446vZTdR6vrCFWL+0hTn7Orp8l1Rk/ym
LLGPUU4iSkRpmYXcQyIwvrxpvROSFr521NFoyr8YcwX7w208FV3spqmfvBSO+Jqm
aQMXowggR9O61YPmrmDT6eXFLnULhTUzbaB3GYT55rh4bkqZZrw9I/Poi2j8DxaI
6wfTQasm4Hi2onyF1AgSpv7/uu4KnrR+FrYQfdkU0peCG1AYEcB8VUREfEOdHsUp
ncVZtZsaFk7NXWPYt0ibdBZbI4uJM4NRAPvQGY4mAgKszZpBJPO7lYvaJIpJJ87C
U9CQ4pIXC2ivgQ2jv5/Ti1vvBfbCwuD+9fUBy8yNZqi13E8El+Jo6WG5KhKCqhet
kkgHOBM8EKPKMpWQIBSv1/mc+HE6NAVz6YPiy41emKSmU8cKwimfF/Zsm8eMsgGx
aL7xEL4WRsgMGJaccRlCcTjk1ETROjMOgaGxBaacxq9QPIN0wKZvmti8HhsZdGsR
8FTQzY7fCmxB2m4S7tSdnIJ88W2glzJmWeHDGCgfcBDU80B1sbY=
=u8iV
-END PGP SIGNATURE-

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

Re: Difficulty of fixing reconciliation

[Peter Lebbing]

On 14/08/2019 12:29, Vincent Breitmoser wrote:
>> The algorithm is designed to withstand very well funded actors,
>> oppressive regimes were what the designers were thinking of.
> 
> We are talking about a sand castle here that was kicked down by a kid. It's
> a bit bizarre to claim that it was built to withstand rockets.

I meant that statement purely and only with regard to deleting data that
had already been in the network, nothing more.

It seems to me that the impossibility of deletion was at the core of the
design of the reconciliation algorithm. To say that we should change the
algorithm to no longer do that seems like claiming we should build
rockets out of sand castles ;-).

> Given that the recon algorithm was designed as a PhD thesis, it seems like
> a safe bet that it was designed to solve the academic problem of set
> reconciliation between distributed systems with optimal message complexity.
> Funny story how it ended up becoming infrastructure for a security ecosystem.

These same statements apply to a *lot* of critical infrastructure in the
Information Technology domain. It's a wonder it usually works well (or
at least gives that appearance when you don't look too hard).

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

[Peter Lebbing]

On 14/08/2019 12:09, Andrew Gallagher wrote:
> Indeed, but that condition is fundamentally incompatible with
> decentralised reconciliation - because deletion without permissions
> management is an open door, and permissions have to be enforced by an
> authority.

H the authority could just be the primary key that the
third-party signatures are over. I'm not talking about the current SKS
keyserver network, but some still-to-be-created federated synchronizing
service.

That authority could also authorize no longer sharing a particular third
party signature, I think. It might still circulate in the federated
network, but any time it rears its head again it could get ignored by
the revoked authorization (or more: authorization to revoke). "Ignoring"
might just mean not offering it to clients even though it's still part
of the federation for technical purposes.

There's a lot of chance for misunderstandings here. I started writing
something less ambiguous and stopped due to the amount of work :-).

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

[Peter Lebbing]

On 14/08/2019 11:39, Alessandro Vesely via Gnupg-users wrote:
> Absolute monotonicity is wrong.  It must be possible to delete errors.

In that case we need a different algorithm.

Which I had already been advocating, so you are preaching to the choir.
You can keep reiterating that you do not like the current algorithm, but
I already got that and I agree.

> Exactly!  That signature is poisoned, delete it.

Which is a denial of service, which I point out in the next paragraph of
the mail you replied to. I'll copy-paste it here with a double
indentation:

>> In neither case will the user get that signature that they actually
>> want, and which according to Murphy is actually near the end of where
>> GnuPG will be looking.

> The defense would try and avoid poisoning.  When a signature is
> poisoned, the defense has failed.

And that's again my very next paragraph:

>> I think the solution needs to be sought in a direction where GnuPG
>> doesn't have to look for valid data amidst a lot of invalid crap.
>> Because evaluating the invalid crap can always be made expensive, so
>> there should be other means to say "I'm not going to parse this, find
>> another way to get me the proper data where it's not buried in crap".

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

[David]

On 13/08/2019 15:54, 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.
> 
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 
Robert,

Can you give me a valid reason why anyone would want their key signed by
150,000 people or more?? How can you meet 150,000 people? Your going to
spend your entire waking hours getting your key signed by as many people
as possible before you die?

The mind boggles!

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

[Vincent Breitmoser via Gnupg-users]

> The algorithm is designed to withstand very well funded actors,
> oppressive regimes were what the designers were thinking of.

We are talking about a sand castle here that was kicked down by a kid. It's
a bit bizarre to claim that it was built to withstand rockets.

Given that the recon algorithm was designed as a PhD thesis, it seems like
a safe bet that it was designed to solve the academic problem of set
reconciliation between distributed systems with optimal message complexity.
Funny story how it ended up becoming infrastructure for a security ecosystem.

 - V


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

Re: Difficulty of fixing reconciliation

[Andrew Gallagher]

On 14/08/2019 10:39, Alessandro Vesely via Gnupg-users wrote:
> Absolute monotonicity is wrong.  It must be possible to delete errors.

Indeed, but that condition is fundamentally incompatible with
decentralised reconciliation - because deletion without permissions
management is an open door, and permissions have to be enforced by an
authority.

>> 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.
> The illegal sig shall be deleted from both servers.

There are three signatures. Which one is illegal? You can't base your
decision on the contents of any of the signatures, because they're
third-party and therefore untrustworthy. Timestamps can be backdated,
for example.

> I'm no expert, but it seems to me that 3rd party signatures should not
> be allowed.  All signing party recipes provide for /exchanging/ sigs,
> but then rely on the fact that Alice can sign Bob's sig before Bob has
> signed Alice's and without Bob's authorization.  That is, the
> semantics is good, but it's not algorithmically enforced.

There's nothing intrinsically wrong with third-party signatures. The
problem is caused by keyservers allowing a global search on the target
id to include all the third party signatures on it, whether the target
consents or not. Unless you use a maximum trust path length of 1, you
must have some way of searching for intermediates.

> Hm... if your sig is signed by a suspect, you become suspect too?  In
> fact, SKS servers with lots of countersigned sigs is manna from heaven
> for police.

A third-party signature is just a statement by someone saying "I know
this person". Sure, that may make you a suspect by association, but so
does mentioning your name in public, or sending you an unsolicited postcard.

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

[Alessandro Vesely via Gnupg-users]

On Tue 13/Aug/2019 13:07:07 +0200 Peter Lebbing wrote:
> 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??)
> 
> [...]
> 
> 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.


Absolute monotonicity is wrong.  It must be possible to delete errors.


> [...skip algorithm for their PhD thesis...]
>
> 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.


The illegal sig shall be deleted from both servers.  (2 is a bit
Procrustean, a reasonable number would be enforceable.)


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


I'm no expert, but it seems to me that 3rd party signatures should not
be allowed.  All signing party recipes provide for /exchanging/ sigs,
but then rely on the fact that Alice can sign Bob's sig before Bob has
signed Alice's and without Bob's authorization.  That is, the
semantics is good, but it's not algorithmically enforced.


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


Hm... if your sig is signed by a suspect, you become suspect too?  In
fact, SKS servers with lots of countersigned sigs is manna from heaven
for police.  I recall someone in the sixties recommending "Comrades,
no phone-books!  Burn them, learn numbers by memory and burn them."

So, would that be a reason to allow 3rd party signatures?  I sign your
sig, but then I also sign a few dozens other random sigs so as to
conceal the link between you and me.  Sounds like a poor trick to me.


>> The bug, however, is in the program that chokes on poisoned keys!
> 
> [...skip very unfavourable runtime <-> data size ratio...]
> 
> So GnuPG gets a key with a lot of third-party signatures. It can keep
> wading through all the crap looking for the real signatures the user
> does want between all the crap added by attackers, and this takes a lot
> of runtime.
> 
> Or it can decide: this is taking to long, I bail out.


Exactly!  That signature is poisoned, delete it.  There might be
utilities that attempt to recover it —much like AV utilities to
recover infected files.


>> Was that fixed, yet?
> 
> How? You keep looking through the piles of crap, or you stop looking. In
> either case, you don't find what you are looking for in a desirable
> length of time.


The defense would try and avoid poisoning.  When a signature is
poisoned, the defense has failed.


> I think the solution needs to be sought in a direction where GnuPG
> doesn't have to look for valid data amidst a lot of invalid crap.
> Because evaluating the invalid crap can always be made expensive, so
> there should be other means to say "I'm not going to parse this, find
> another way to get me the proper data where it's not buried in crap".


Agreed.


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

[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