Mailing List Archive

Re: [Sks-devel] [openpgp-email] Keyservers and GDPR
> On 6 Nov 2018, at 16:57, Volker Birk <vb@pep-project.org> wrote:
>
> I'm not of the opinion that key servers are a good idea at all. It's
> a pity that people still follow this wrong idea.

There are other methods for discovery that don’t suffer from the same weaknesses, but there is no equally resilient method of distributing revocations.

A

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: [Sks-devel] [openpgp-email] Keyservers and GDPR [ In reply to ]
> On 7 Nov 2018, at 10:16, Yegor Timoshenko <yegortimoshenko@riseup.net> 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.

A

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: [Sks-devel] [openpgp-email] Keyservers and GDPR [ In reply to ]
On 07.11.2018 11:50, Andrew Gallagher wrote:
>
>> On 7 Nov 2018, at 10:16, Yegor Timoshenko <yegortimoshenko@riseup.net> 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

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: [Sks-devel] [openpgp-email] Keyservers and GDPR [ In reply to ]
On Wed, 7 Nov 2018 11:50, andrewg@andrewg.com said:

> significantly affecting legitimate use. It may stop people uploading
> warez but it can’t prevent cheap vandalism.

Free storage to upload arbitrary data is easily available (e.g. p2p,
free mail accounts). Having a searchable index to that data is more
challenging. Thus removing the search capability from the keyservers
will render its free-as-in-beer storage feature mostly useless.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: [Sks-devel] [openpgp-email] Keyservers and GDPR [ In reply to ]
> On 7 Nov 2018, at 16:43, Yegor Timoshenko <yegortimoshenko@riseup.net> wrote:
>
> It's not just storage, it's also immutable and distributed.

In the keyservers, removing immutable content is a Very Hard Problem, but it is theoretically possible.

With blockchain, it is impossible by design.

A

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: [Autocrypt] [Sks-devel] [openpgp-email] Keyservers and GDPR [ In reply to ]
On Wed, 2018-11-07 at 17:34 +0100, Werner Koch wrote:
> Thus removing the search capability from the keyservers
> will render its free-as-in-beer storage feature mostly useless.
Only if you assume that nobody creates such an index.

Cheers,
Tobi


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: [Autocrypt] [Sks-devel] [openpgp-email] Keyservers and GDPR [ In reply to ]
Hi,

On Wed, 2018-11-07 at 12:33 +0100, Wiktor Kwapisiewicz via Autocrypt
wrote:
> If cryptographic verification was enough for X.509 there
> wouldn't be Certificate Transparency
CT solves a slightly different set of problems related to
the centralised trust model that we don't necessarily have.

That said, I think we can store revocations in the CT logs s.t. we can
at least have integrity protection and non-equivocation for those. Both
properties which we currently do not have when fetching them from the
key server.


Cheers,
Tobi


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: [Autocrypt] [Sks-devel] [openpgp-email] Keyservers and GDPR [ In reply to ]
Hello,

On 07.11.2018 18:17, Tobias Mueller wrote:
> That said, I think we can store revocations in the CT logs s.t. we can
> at least have integrity protection and non-equivocation for those. Both
> properties which we currently do not have when fetching them from the
> key server.

Mozilla experimented with storing release hashes of Firefox in CT logs:
https://wiki.mozilla.org/Security/Binary_Transparency

They used Merkle tree so the amount of data stored is small (just the
tree head) compared to the OpenPGP revocation.

Kind regards,
Wiktor

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

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: [Autocrypt] [Sks-devel] [openpgp-email] Keyservers and GDPR [ In reply to ]
On Wed, 7 Nov 2018 18:07, muelli@cryptobitch.de said:

> Only if you assume that nobody creates such an index.

But then it is not a problem for keyserver operators (except for load
issues).


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.