[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sks-devel] GDPR (equine corpse)
From: |
brent s. |
Subject: |
Re: [Sks-devel] GDPR (equine corpse) |
Date: |
Sat, 17 Aug 2019 17:57:06 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 |
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
- Re: [Sks-devel] The pool is shrinking, (continued)
- Re: [Sks-devel] The pool is shrinking, Hendrik Visage, 2019/08/16
- Re: [Sks-devel] The pool is shrinking, Stefan Claas, 2019/08/16
- [Sks-devel] GDPR (equine corpse) (WAS: Re: The pool is shrinking), brent s., 2019/08/16
- Re: [Sks-devel] GDPR (equine corpse) (WAS: Re: The pool is shrinking), Robert J. Hansen, 2019/08/17
- Re: [Sks-devel] GDPR (equine corpse) (WAS: Re: The pool is shrinking), Stefan Claas, 2019/08/17
- Re: [Sks-devel] GDPR (equine corpse) (WAS: Re: The pool is shrinking), brent s., 2019/08/17
- Re: [Sks-devel] GDPR (equine corpse), Stefan Claas, 2019/08/17
- Re: [Sks-devel] GDPR (equine corpse), brent s., 2019/08/17
- Re: [Sks-devel] GDPR (equine corpse), Stefan Claas, 2019/08/17
- Re: [Sks-devel] GDPR (equine corpse), Tobias Frei, 2019/08/17
- Re: [Sks-devel] GDPR (equine corpse),
brent s. <=
- Re: [Sks-devel] GDPR (equine corpse), Todd Fleisher, 2019/08/17
- Re: [Sks-devel] GDPR (equine corpse), Stefan Claas, 2019/08/17
- Re: [Sks-devel] GDPR (equine corpse), Todd Fleisher, 2019/08/17
- Re: [Sks-devel] GDPR (equine corpse), Stefan Claas, 2019/08/17
- Re: [Sks-devel] GDPR (equine corpse) (WAS: Re: The pool is shrinking), Tobias Mueller, 2019/08/20
- Re: [Sks-devel] GDPR (equine corpse) (WAS: Re: The pool is shrinking), brent s., 2019/08/20
- Re: [Sks-devel] The pool is shrinking, Stefan Claas, 2019/08/16
- Re: [Sks-devel] The pool is shrinking, Andrew Gallagher, 2019/08/16
- Re: [Sks-devel] The pool is shrinking, Robert J. Hansen, 2019/08/16
Re: [Sks-devel] The pool is shrinking, Kiss Gabor (Bitman), 2019/08/16