Re: [Sks-devel] GDPR (equine corpse)

[brent s.]

On 8/17/19 4:44 PM, Tobias Frei wrote:
> 
> 
> On Aug 17, 2019 19:11, Stefan Claas <address@hidden> wrote:
> 
>     Interesting! If understood correctly the advantage then would be no
>     changes
> 
>     in the SKS code and simply using a front-end key parser, with a
>     defined rule
>     set, right?
> 
> And false positives. And ineffectiveness against new attacks. And
> vulnerability through peering unless everyone runs the same frontend
> parser, which, if distributed together with SKS, is basically an
> amendment (I would say "change"?) to the SKS code. Interesting mainly
> for the reasons it fails for.
> 
> Besr regards 
> Tobias Frei
> 


Yep, +1 - this is what I meant in part by "which is always going to be
faulty to some degree and just ends up as a cat-and-mouse game."

Heuristic analysis is *really* hard to do... well, effectively at all.
It's more of a fun thought experiment than anything. ;) As Tobias points
out above, you're now no longer just depending on the same RECON
protocol being supported between keyservers, but they also have to share
the exact same heuristic ruleset/filters, engine, etc. - otherwise you
end up with an issue with keyservers endlessly disagreeing on which keys
to sync. Which is a different form of one of the current issues in
peering (there's a couple HUGE keys that churn CPU and tend to fail out
when trying to sync).

I think we all agree that the SKS code could use some modernization[0]
and modifications, Stefan; it's just that nobody has any good ideas for
*how* to fix these problems without creating *more* problems in such a
way that won't totally break the purpose and design of decentralized
public cryptography/identity verification/etc.


[0] I don't care what language it's written in, but it won't
compile/process in anything newer than OCAML/CAMLP 4.05 in my attempts.

-- 
brent saner
https://square-r00t.net/
GPG info: https://square-r00t.net/gpg-info

signature.asc
Description: OpenPGP digital signature