sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] Oh, Jeeez...!


From: Daniel Kahn Gillmor
Subject: Re: [Sks-devel] Oh, Jeeez...!
Date: Fri, 27 May 2016 10:19:12 -0400
User-agent: Notmuch/0.22+16~g87b7bd4 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu)

On Fri 2016-05-27 07:54:50 -0400, Pascal Levasseur wrote:
> Suppose we add a POW data to the PGP key data transaction request
>
> We can use the number of 0 in the 160-bit SHA-1 hash as the level of
> complexity indicator.
>
> The servers who receive a request from an user software to add a key can
> easily check the number of zero to find the level of POW and accept or
> not the request.
>
> The same mechanism can be used between servers for database reconciliation.
>
> Please feel free to find the weaknesses in this suggestion !!!

I think this is the most elegant mechanism proposed yet, but it's still
missing some details due to the composability of OpenPGP certificates --
a certificate can be constructed piecemeal (e.g. some user IDs can be
omitted), and parts of the certificate can even be freely re-ordered
(e.g. signature packets over a given user ID have no defined preferred
ordering), and some parts can actually be freely modified without
breakage (e.g. the non-hashed subpackets in a signature packet).

None of this really matters for initial submission -- the data hashed is
the full OpenPGP certificate submitted, so it works there.

But one of the jobs of keyservers is to coalesce all submitted material
related to a single primary key into a well-formed OpenPGP certificate
composed of the union of all submitted parts, and synchronization
happens across those parts.  So it's not clear to me how a keyserver
would propagate the PoW information to other keyservers once the
aggregate was formed.

But more importantly, we have to ask the question of who a PoW scheme
protects.  It basically privileges those who have access to more compute
power, in an attempt to defend the network against malicious flooders.
If that's a fair characterization of the goals, i'm not convinced it's a
coherent idea in the real world.  Malicious flooders are as likely (if
not moreso) to have access to distributed compute farms or botnets than
legitimate users.  So while PoW might slow the rate of a flood, it's
unlikely to be an effective long-term barrier.

I wish i had a better solution to propose.

           --dkg

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]