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

On 27 May 2016, at 15:35, Christoph Egger wrote: > > These bulk bullshit submissions are the mostly-harmless branch of the > problem. The way more pressing thing is > > a) distributing unlawfull / unethical data and having no way to get > rid of it (starting

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

Andrew Gallagher dijo [Fri, May 27, 2016 at 04:24:33PM +0100]: > On 27/05/16 15:19, Daniel Kahn Gillmor wrote: > > 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

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

> Please feel free to find the weaknesses in this suggestion !!! Fine. Remember: you asked for it. > 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. In *which* SHA-1 hash? > The

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

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

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

Is there a common element to the bulk signatures that are being added? Can we, maybe, rate limit submissions per IP address? Alternatively, the sync can be stopped after a prescribed number of differences have been identified ... this will have the effect of slowing new key updates over time.

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

On 05/24/2016 06:33 AM, Kiss Gabor (Bitman) wrote: > Have you remembered I'm continuosly worrying about > trolls pumping 10-20 millions of dummy keys into key servers? > It is started... Is there a technical reason why a keyserver like SKS can't remain append-only but require that all submitted

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

On 27/05/16 12:54, Pascal Levasseur wrote: > > Please feel free to find the weaknesses in this suggestion !!! The fundamental weakness in the proof of work requirement is trying to apply it in a complex, distributed, synchronising system. The natural place to require proof-of-work is in the

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

Pascal Levasseur wrote: > > Please feel free to find the weaknesses in this suggestion !!! You have no knowledgeable people to implement it. -- Kim Minh. ___ Sks-devel mailing list Sks-devel@nongnu.org

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

Le 26/05/2016 18:51, Robert J. Hansen a écrit : >> The administrators of the SKS servers should be able to choose the level >> of complexity of the proof of work using a parameter in the SKS server >> configuration file. > > No, they shouldn't. Think about it. If you're an attacker looking to

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

I have a few thoughts, if I may. If I understand the gist of this discussion you're trying to clean up bad entries and add a support to delete such entries on a regular basis. I think this is a dangerous idea, maybe not completely bad, but IMHO it requires very careful thought. The reason is

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

> The administrators of the SKS servers should be able to choose the level > of complexity of the proof of work using a parameter in the SKS server > configuration file. No, they shouldn't. Think about it. If you're an attacker looking to bypass this mechanism, what do you do? You find the

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

> Let client solve a simple integer factorization of a random number given > by server with e.g. 64bit build from two prime numbers. Please sanity-check your ideas first. Trial division on a 64-bit number requires trying each prime up to 2**32. There are about 200 million of them. 200 million

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

Am 25.05.2016 um 18:13 schrieb Valentin Sundermann: Hi, Can we add a proof of work mechanism to make adding a key to the server more "costly" ?. Let client solve a simple integer factorization of a random number given by server with e.g. 64bit build from two prime numbers. Client has to

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

Hi, > Can we add a proof of work mechanism to make adding a key to the server > more "costly" ?. There are some blockchain based approaches on how to distribute keys (or managing identity) like Blockstack(.org) with their "blockchain id". Their current model is, that you order a normal name (like

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

At Wed, 25 May 2016 00:04:05 +0200, Arnold wrote: > > On 24-05-16 18:17, Tobias Frei wrote: > > Adding proof of work can only prevent an attack that depends on a huge > > number of > > useless keys. > > Setting a maximum upload size can help and is easy to implement locally. > Further, > it is

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

On 24-05-16 18:17, Tobias Frei wrote: > Adding proof of work can only prevent an attack that depends on a huge number > of > useless keys. Setting a maximum upload size can help and is easy to implement locally. Further, it is possible to limit the rate at which a single IP (or IPv6/64) can

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

Tobias Frei writes: > About lacking keys, well, if the pool selection mechanism causes > working keyservers to be removed, that's a separate problem that needs > to be solved after this one, I think. It should not be an argument for > or against this suggestion, but

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

Hi, Adding proof of work can only prevent an attack that depends on a huge number of useless keys. Someone else once mentioned that a single key with an illegal image ID can already cause huge problems, and deleting such a key can become the only way to be legally allowed to continue running a

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

Le 24/05/2016 06:33, Kiss Gabor (Bitman) a écrit : > Guys, > > Have you remembered I'm continuosly worrying about > trolls pumping 10-20 millions of dummy keys into key servers? > It is started... > > http://keys.niif.hu/pks/lookup?op=vindex=0x0B7F8B60E3EDFAE3 > (Scroll over the whole page.) >

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

> I think the only reasonable solution is that every server operator gets a > local blacklist that can be filled with keys / signatures / regex etc. and > that only prevents matched entries from being saved to the database. To > remove a key from all servers, all operators would need to add it to

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

Zitat von Tobias Frei : Hi, to be honest, it somehow makes me happy that we're finally being forced to find a solution for this. It could have started worse. I think the only reasonable solution is that every server operator gets a local blacklist that can be filled

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

Hi, to be honest, it somehow makes me happy that we're finally being forced to find a solution for this. It could have started worse. I think the only reasonable solution is that every server operator gets a local blacklist that can be filled with keys / signatures / regex etc. and that only

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

Guys, Have you remembered I'm continuosly worrying about trolls pumping 10-20 millions of dummy keys into key servers? It is started... http://keys.niif.hu/pks/lookup?op=vindex=0x0B7F8B60E3EDFAE3 (Scroll over the whole page.) So we must hard think how to delete keys/signatures. Gabor