The pool is shrinking

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
91 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: GDPR (equine corpse)

Stefan Claas
brent s. wrote:

> I'm going to anticipate what you're suggesting this solves - that only
> key owners can upload their own key by ensuring the sender matches one
> of the key's identities. There's flaws with that:
>
> 1.) You've now broken the ability to upload keys with no real
> identifiable information (i.e. no real email address), thus *forcing*
> users of a keyserver to provide personal identifiable information. This
> breaks anonymity.

Anonymity is a very important point when one likes to communicate securely
and anonymously!

For that purpose Anonymous Remailers with a Nym account are in service
for many years. It requires on the users side that he / she is familiar
with GPG, to create a Nym account.

http://is-not-my.name/

The Remailer Software itself (Mixmaster) is included in Linux distributions.
Windows users have Mixmaster clients too. One only needs a free Usenet
account to pick up messages from the News Group alt.anonymous.messages.

Then there are probably still free anonymous Tor email accounts available.

Another option would be to set-up an email to Bitmessage Gateway (like
Mailchuck) so that GPG users can submit their keys from within the Bitmessage
client to the key server via the email Gateway.

https://github.com/V07D/bitmessage-email-gateway

The other points you have mentioned, like the signer cannot upload a key,
well that's true but I wonder how you guys like then to solve the problem
with uploading flooded key material to the key servers. I think you can
not have all options, but I am all ears.

Regards
Stefan
--
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD)

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: GDPR (equine corpse)

brent s.
On 8/17/19 11:46 AM, Stefan Claas wrote:

> Anonymity is a very important point when one likes to communicate securely
> and anonymously!
>
> For that purpose Anonymous Remailers with a Nym account are in service
> for many years. It requires on the users side that he / she is familiar
> with GPG, to create a Nym account.
>
> http://is-not-my.name/
>
> The Remailer Software itself (Mixmaster) is included in Linux distributions.
> Windows users have Mixmaster clients too. One only needs a free Usenet
> account to pick up messages from the News Group alt.anonymous.messages.
Except no, because now you aren't talking about email anymore, you're
adding an *additional* layer of complexity. Additionally, I'm talking
about a key with *no email address whatsoever*. Again, this is an OPSEC
issue. Your proposal still requires an additional external piece of PII,
as "anonymous" as it may be.

>
> Then there are probably still free anonymous Tor email accounts available.
>
> Another option would be to set-up an email to Bitmessage Gateway (like
> Mailchuck) so that GPG users can submit their keys from within the Bitmessage
> client to the key server via the email Gateway.
>
> https://github.com/V07D/bitmessage-email-gateway

Again, see above. This is no longer email you're talking about. Further,
it still requires *a valid PII to validate the key reception*. Further
still, it creates an additional dependence on a third-party provider. No
bueno.

>
> The other points you have mentioned, like the signer cannot upload a key,
> well that's true but I wonder how you guys like then to solve the problem
> with uploading flooded key material to the key servers. I think you can
> not have all options, but I am all ears.
>
> Regards
> Stefan
>

Hence the original discussion, yes. The only way to do it that I can
think if is one (or both) of:

- blacklisting keys, which makes the server peering *incredibly* more
complex (and, it can be made the case for, impossible) - if you were
following this mailing list for a while, you'd have seen us discuss this
very issue many, many times. For something like 8 months now. Check the
archives.

- heuristic analysis, which is always going to be faulty to some degree
and just ends up as a cat-and-mouse game.



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


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (916 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GDPR (equine corpse)

Stefan Claas
brent s. wrote:

> On 8/17/19 11:46 AM, Stefan Claas wrote:

> > The other points you have mentioned, like the signer cannot upload a key,
> > well that's true but I wonder how you guys like then to solve the problem
> > with uploading flooded key material to the key servers. I think you can
> > not have all options, but I am all ears.
> >
> > Regards
> > Stefan
> >
>
> Hence the original discussion, yes. The only way to do it that I can
> think if is one (or both) of:
>
> - blacklisting keys, which makes the server peering *incredibly* more
> complex (and, it can be made the case for, impossible) - if you were
> following this mailing list for a while, you'd have seen us discuss this
> very issue many, many times. For something like 8 months now. Check the
> archives.

Will do.

> - heuristic analysis, which is always going to be faulty to some degree
> and just ends up as a cat-and-mouse game.

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?

Regards
Stefan

--
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD)

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: GDPR (equine corpse)

Tobias Frei


On Aug 17, 2019 19:11, Stefan Claas <[hidden email]> 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

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: GDPR (equine corpse)

Todd Fleisher
In reply to this post by Stefan Claas
On Aug 17, 2019, at 8:46 AM, Stefan Claas <[hidden email]> wrote:

Anonymity is a very important point when one likes to communicate securely
and anonymously!

For that purpose Anonymous Remailers with a Nym account are in service
for many years. It requires on the users side that he / she is familiar
with GPG, to create a Nym account.

http://is-not-my.name/

This could be considered a bit pedantic … but I would consider a website serving content over unencrypted http and using an invalid SSL certificate for serving https traffic to be neither anonymous nor secure: https://i.imgur.com/drVX1EX.jpg

-T


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: GDPR (equine corpse)

brent s.
In reply to this post by Tobias Frei
On 8/17/19 4:44 PM, Tobias Frei wrote:

>
>
> On Aug 17, 2019 19:11, Stefan Claas <[hidden email]> 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


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (916 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GDPR (equine corpse)

Stefan Claas
In reply to this post by Todd Fleisher
Todd Fleisher wrote:

> > On Aug 17, 2019, at 8:46 AM, Stefan Claas <[hidden email]
> > <mailto:[hidden email]>> wrote:
> >
> > Anonymity is a very important point when one likes to communicate securely
> > and anonymously!
> >
> > For that purpose Anonymous Remailers with a Nym account are in service
> > for many years. It requires on the users side that he / she is familiar
> > with GPG, to create a Nym account.
> >
> > http://is-not-my.name/ <http://is-not-my.name/>
>
> This could be considered a bit pedantic … but I would consider a website
> serving content over unencrypted http and using an invalid SSL certificate
> for serving https traffic to be neither anonymous nor secure:
> https://i.imgur.com/drVX1EX.jpg <https://i.imgur.com/drVX1EX.jpg>

Well, it is only a very old information page. The usage of those Nyms is secure,
in combination with Mixmaster.

People not trusting such a service may check out the source code and set-up
their own Nym Server.

https://github.com/crooks/nymserv

There are two more Nym servers available, which I forgot to mention:

https://remailer.paranoici.org/nym.php

https://thinhose.net/

Regards
Stefan

--
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD)

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: GDPR (equine corpse)

Todd Fleisher
On Aug 17, 2019, at 18:00, Stefan Claas <[hidden email]> wrote:

Todd Fleisher wrote:

On Aug 17, 2019, at 8:46 AM, Stefan Claas <[hidden email]
<[hidden email]>> wrote:

Anonymity is a very important point when one likes to communicate securely
and anonymously!

For that purpose Anonymous Remailers with a Nym account are in service
for many years. It requires on the users side that he / she is familiar
with GPG, to create a Nym account.

http://is-not-my.name/ <http://is-not-my.name/>

This could be considered a bit pedantic … but I would consider a website
serving content over unencrypted http and using an invalid SSL certificate
for serving https traffic to be neither anonymous nor secure:
https://i.imgur.com/drVX1EX.jpg <https://i.imgur.com/drVX1EX.jpg>

Well, it is only a very old information page. The usage of those Nyms is secure,
in combination with Mixmaster.

People not trusting such a service may check out the source code and set-up
their own Nym Server.

https://github.com/crooks/nymserv

There are two more Nym servers available, which I forgot to mention:

https://remailer.paranoici.org/nym.php

https://thinhose.net/

Regards
Stefan

Thanks for providing these links, I'll have to check them out. I haven't used an anonymous remailer since anon.penet.fi went dark over two decades ago 



_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: GDPR (equine corpse)

Stefan Claas
Todd Fleisher wrote:
 
> Thanks for providing these links, I'll have to check them out. I haven't used
> an anonymous remailer since anon.penet.fi went dark over two decades ago
>
> https://en.m.wikipedia.org/wiki/Penet_remailer

You're welcome! Yes, good old penet. ;-)

Regards
Stefan

--
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD)

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: GDPR (equine corpse) (WAS: Re: The pool is shrinking)

Tobias Mueller
In reply to this post by brent s.
Hi,

On Fri, 2019-08-16 at 19:28 -0400, brent s. wrote:
> SO for starters, please keep this off the "pool is shrinking" thread.
> I'd like to see that thread relevant to resolving resiliency issues of
> the SKS network, given that's the actual purpose behind starting that
> thread. GDPR is off-topic to that thread and, quite frankly, it's
> getting *extremely* annoying seeing GDPR bickering in a thread I'm
> trying to follow for technical solutions to an actual technical
> problem.
I understand you and I think many of us are in the same boat.
Yet, let me quickly refute a statement of yours before it becomes
folklore.


> Take special notice of Article 89[3].
>
> This means not only are keydumps allowed for research (§2), but the
> SKS in general (ESPECIALLY US servers and operators, which I'll get to
> in a moment) is exempt - we provide "...archiving purposes in the
> public interest" (§3). Frankly put, we make GPG *work*. GPG is a
> *very* valuable public tool - zero-trust-model public cryptography is
> impossible without the Web-of-Trust. Ergo, exempt. It's that simple.
No. And no, it's not.
You are reading this wrongly.
§89 says that member states *can* enact laws which exempt controllers
from their duties with respect to erasure or correction *iff* the
legitimate ground is the public interest (which itself is highly
questionable).
You don't gain anything from this §89 GDPR if member states do not
create a law. And even then you wouldn't be fully exempt (as you
suggest), but rather have an easier life as a controller.
If we require member states to enact laws, then we're better off
pursuing laws based on §85 GDPR, but that'd go too far for this
discussion here.  I'm happy to have this elsewhere.

Cheers,
  Tobi


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: GDPR (equine corpse) (WAS: Re: The pool is shrinking)

brent s.
On 8/20/19 6:05 AM, Tobias Mueller wrote:
(SNIP)

>> This means not only are keydumps allowed for research (§2), but the
>> SKS in general (ESPECIALLY US servers and operators, which I'll get to
>> in a moment) is exempt - we provide "...archiving purposes in the
>> public interest" (§3). Frankly put, we make GPG *work*. GPG is a
>> *very* valuable public tool - zero-trust-model public cryptography is
>> impossible without the Web-of-Trust. Ergo, exempt. It's that simple.
> No. And no, it's not.
> You are reading this wrongly.
> §89 says that member states *can* enact laws which exempt controllers
> from their duties with respect to erasure or correction *iff* the
> legitimate ground is the public interest (which itself is highly
> questionable).
> You don't gain anything from this §89 GDPR if member states do not
> create a law. And even then you wouldn't be fully exempt (as you
> suggest), but rather have an easier life as a controller.
> If we require member states to enact laws, then we're better off
> pursuing laws based on §85 GDPR, but that'd go too far for this
> discussion here.  I'm happy to have this elsewhere.
>
> Cheers,
>   Tobi
>

Sure; while §17(d) makes allowance via §89, it would - for example -
require a UK operator to associate with the Nat'l Registry of
Archives[0] to get the furthest extent of legal coverage (under §89
*specifically*).

However, the GDPR also makes exemption for TEU, Title V (2)(b) as well
without requiring a member state to make allowance. So an EU operator
could, should they fear GDPR repercussions, either 1.) pursue enacted
legislation/established archival status within their member state to
come under protection of §89 OR 2.) appeal to be a provider a service
under TEU Title V.

Worth noting that Article 23 of GDPR also allows derogations for public
security as well.

HOWEVER, also note that *processing* of keys would fall under Article 6
(1)(f) (legitimate interest being defined via Recital 49) which requires
no explicit derogation of member states. Being that the public key is
necessary for the operation of the processing of keys in the duties of
"...preventing .. malicious code distribution"(Recital 49)(though GPG
itself serves a much broader use to protect the rights and freedoms of
EU citizens as well, which are widely covered throughout the GDPR) -
such as GPG signatures on release tarballs, for instance - the erasure
situation can be considered covered as well.

GPG *also* enables compliance with Article 32(1)(a) and (b).

Of course, this is all untested because to my knowledge an EU keyserver
operator hasn't been challenged and it hasn't been brought to an EU
court yet, so there's no established example. But the case is quite
strong for the keyserver operator, I'd say.



[0] https://www.nationalarchives.gov.uk/

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


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (916 bytes) Download Attachment
12345