On 07/02/2019 11:42 PM, Michał Górny wrote: > Dnia July 3, 2019 6:23:37 AM UTC, Mirimir via Gnupg-users > <gnupg-users@gnupg.org> napisał(a):
<SNIP> >> I don't think that it's necessary to stop using SKS keyservers. And I >> suspect that doing so would be nontrivial. Given that requests to them >> are likely hard-coded, or buried in obscure options and preferences. >> Stuff that nobody has touched for years. >> >> I believe that the most practical approach is 1) efficiently finding >> toxic keys, and 2) reconfiguring keyservers not to serve them. I get >> that many find this distasteful, doing the attackers' work for them, >> etc, etc, etc. But it would limit damage, to the extent that toxic keys >> can be identified soon enough. And there are other ways to share good >> copies of those keys. Via Keybase, for example. Or as you say, >> manually. > > I don't think this is going to work long term. Even if you manage to > somehow synchronously control all servers in SKS rotation, there's no > way to prevent attackers from poisoning them over and over again. I'm not suggesting any controls on a server-by-server basis. I'm suggesting that blacklisting of toxic keys be a software update. And as the Tor network does, keyservers would ignore peers running outdated versions. Also, if what I propose is workable, toxic keys won't matter. They'll just be wasted space on the keyservers. And indeed, "poisoning them over and over again" isn't at all an issue. Given that toxic keys, or the signatures that poison them, can't actually be removed. By design, to prevent censorship. > Then, they may decide to start mass poisoning other keys just to > prove this is not the right solution. If what I propose is workable, attackers can poison as many keys as they like. Until SKS keyservers go down, anyway. Until then, if the system catches them quickly enough, they won't do widespread damage. They'll inconvenience some people, of course, but that seems unavoidable. And as an extra benefit, this would nuke file systems that store data in signatures. <SNIP> _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users