sks-devel
[Top][All Lists]
Advanced

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

Re: [Sks-devel] [openpgp-email] Keyservers and GDPR


From: Wiktor Kwapisiewicz
Subject: Re: [Sks-devel] [openpgp-email] Keyservers and GDPR
Date: Wed, 7 Nov 2018 12:33:00 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0

On 07.11.2018 11:50, Andrew Gallagher wrote:
> 
>> On 7 Nov 2018, at 10:16, Yegor Timoshenko <address@hidden> wrote:
>>
>> World-writable storage is problematic even if there is no search.
>> Proof of work and some operator-controllable data removal
>> mechanism (like opt-in key blacklists) can help limit this attack
>> vector.
>>
>> Storing immutable data, distributed recon, proof of work, that
>> sounds like something a blockchain should do to me.
> 
> More evidence that blockchain is a solution in search of a problem! :-)
> 
> Proof of work verification provides little benefit over cryptographic 
> verification. If you have already generated a valid signature, that is in 
> itself a proof of work. The only reason you would also use hashcash is if you 
> wanted to increase the difficulty of the work beyond what the cryptography 
> itself provides. But hashcash only works if it is possible to find a 
> difficulty level that impedes abuse while not significantly affecting 
> legitimate use. It may stop people uploading warez but it can’t prevent cheap 
> vandalism. 

Blockchain can be used to timestamp data in a way that is evident to a
broad audience. If cryptographic verification was enough for X.509 there
wouldn't be Certificate Transparency (that uses similar primitives) and
CT is required for all issued "SSL certificates" today [0].

For OpenPGP that would mean keeping the keyservers accountable: not
letting them return different responses for different people, or
omitting some data (e.g. revocations).

There are already projects that tackle this very problem:
  - https://coniks.cs.princeton.edu/about.html
  -
https://security.googleblog.com/2017/01/security-through-transparency.html
  -
https://blog.okturtles.org/2017/02/coniks-vs-key-transparency-vs-certificate-transparency-vs-blockchains/

(For the record I'm not advocating for using blockchain, but even a
buzzword tech should be evaluated purely on its merits)

Kind regards,
Wiktor

[0]:
https://www.thesslstore.com/blog/certificate-transparency-april-30-2018/

-- 
https://metacode.biz/@wiktor



reply via email to

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