Re: [Sks-devel] key dump

[Tobias Mueller]

Heya :)

On Fri, Jun 08, 2012 at 10:11:11AM +0200, Sebastian Urbach wrote:
> [...] if something goes wrong
> with the import. Better loose 5000 than 15000 keys.
For the fun of it, I tried to parse a few weekly dumps and very often, 
not even GPG can successfully parse the packets, i.e. gpg --list-packets 
fails. Usually with "gpg: mpi too large for this implementation (56104 
bits)" but there is a myriad of errors, i.e.
gpg: subpacket of type 16 too short
gpg: mpi larger than indicated length (517 bytes)
gpg: mpi larger than indicated length (0 bytes)
gpg: signature packet: unhashed data too long
gpg: signature packet: hashed data too long
gpg: mpi larger than indicated length (514 bytes)
gpg: packet(14) too short

I usually can parse 30 to 40 out of the 206 or 207 dumps (probably 
containing 15k keys each).

So I appreciate that the dumps will contain less keys.

I wonder why that is though.
Do I have I download or memory problems (on multiple machines..?)?
Is that just malicious data which landed in the pool?
Or is SKS better on parsing OpenPGP packets than GnuPG? Because one 
offending key seems to be 0x5df5c3733a6ced98 which, according to 
http://gpg.spline.inf.fu-berlin.de:11371/pks/lookup?search=0x5DF5C3733A6CED98&fingerprint=on&hash=on&op=vindex
 
is successfully parsed by SKS. Same thing for 0xb51b4b095356aac8 or 
0x857625223295AAB2.
It appears to be keys that carry signature from 0x9710B89BCA57AD7C, the 
"PGP Global Directory Verification Key".

Cheers,
  Tobi

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] memory leak: solved

[Tobias Mueller]

Hi.

On Fr, 2015-04-10 at 17:18 -0400, Daniel Kahn Gillmor wrote:
> I consider this a bug in SKS, if it can overconsume RAM on the basis
> of one misbehaving or rejecting peer.
> 
> the implication is that a network attacker can force any SKS server
> into this state.
> 
> Have you filed a bug report about this?
Has this been done?
Where is the bug tracker, anyway?

Cheers,
  Tobi


___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Analyzing key server data

[Tobias Mueller]

Hi Hanno!

On So, 2015-03-22 at 12:58 +0100, Hanno Böck wrote:
> Code:
> https://github.com/hannob/pgpecosystem
> 
This is great work, thanks.

I tried to parse SKS dumps in the past, but I failed miserably, using
python-openpgp.
I'm looking forward to seeing your implementation.

Have you seen the Analysing the Web of Trust paper?
http://link.springer.com/chapter/10.1007/978-3-642-23822-2_27
http://dl.acm.org/citation.cfm?id=844108

There is also .

Cheers,
  Tobi


___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Analyzing key server data

[Tobias Mueller]

Hi!

On Mon, Jul 06, 2015 at 08:22:48AM -0700, Daniel Roesler wrote:
> Ok, just confirmed that openpgp-python can still parse the pool.
Cool! Thanks for that.

> Do you have a public key that throws an exception?
I tried a couple of years back:
http://lists.nongnu.org/archive/html/sks-devel/2012-06/msg00025.html

Cheers,
  Tobi

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] [Autocrypt] [openpgp-email] Keyservers and GDPR

[Tobias Mueller]

Hi,

On Wed, 2018-11-07 at 10:13 +0100, Werner Koch wrote:
> This requires that there are no rogue keyservers in the network and
> that
> in turn means that they are under the control of a single entity.
It depends on your use case, but you might be happy enough if you have a
proof of who introduced the malicious data.

That said, you might as well establish a network adhering to certain
rules run by people who are trusted enough by its users. That may not
necessarily be Google, but the EFF, the CCC, or the DPAs of the EU
member states.

Cheers,
  Tobi


___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] [Autocrypt] [openpgp-email] Keyservers and GDPR

[Tobias Mueller]

On Wed, 2018-11-07 at 17:34 +0100, Werner Koch wrote:
> Thus removing the search capability from the keyservers
> will render its free-as-in-beer storage feature mostly useless.
Only if you assume that nobody creates such an index.

Cheers,
  Tobi


___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] [Autocrypt] [openpgp-email] Keyservers and GDPR

[Tobias Mueller]

Hi,

On Wed, 2018-11-07 at 12:33 +0100, Wiktor Kwapisiewicz via Autocrypt
wrote:
> If cryptographic verification was enough for X.509 there
> wouldn't be Certificate Transparency
CT solves a slightly different set of problems related to
the centralised trust model that we don't necessarily have.

That said, I think we can store revocations in the CT logs s.t. we can
at least have integrity protection and non-equivocation for those. Both
properties which we currently do not have when fetching them from the
key server.


Cheers,
  Tobi


___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] sks.daylightpirates.org is staying...again

[Tobias Mueller]

Hi,

On Wed, 2018-11-21 at 15:42 -0800, Todd Fleisher wrote:
> onto the public SKS network that many people rely on every day.
do we have actual numbers here?

Cheers,
  Tobi


___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Keyservers and GDPR

[Tobias Mueller]

Hi,


On Mon, 2019-05-13 at 19:35 +0200, ilf wrote:
> So far, I stand by last year's statement:
> 
> > tl;dr: Keep calm and keep running keyservers.
> 
Are you standing by your statement because you believe that processing
that data is lawful or because you don't fear the consequences of a
potentially unlawful processing of data?

Cheers,
  Tobi


___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] The pool is shrinking

[Tobias Mueller]

Hi,

On Tue, 2019-08-13 at 11:00 -0400, Robert J. Hansen wrote:
> > They are!
> 
> No, they're not.
I think your assessment is wrong.

> 
> There are (or at least were) a large number of US-based keyserver
> operators who were immune to the GDPR.

I fail to see how this is in accordance with the GDPR.
Section 3.2 states¹:

> This Regulation applies to the processing of personal data of data
> subjects who are in the Union by a controller or processor not
> established in the Union, where the processing activities are related
> to:
> 
> the offering of goods or services, irrespective of whether a
> payment of the data subject is required, to such data subjects in the
> Union

This is exactly the case for OpenPGP Keyservers.

Cheers,
  Tobi

1: https://gdpr-info.eu/art-3-gdpr/ 


___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] The pool is shrinking

[Tobias Mueller]

Hi,

On Tue, 2019-08-13 at 11:59 -0400, Robert J. Hansen wrote:
>   If I, as a US citizen with no
> overseas business ties, receive a GDPR notice, I'm going to laugh and
> throw it away as it's not binding within the US.  The EU can't even
> haul me into court over it.
Fair enough. Then you're ignoring the consequences (or rather believe
that none exist) rather than saying that the GDPR wouldn't apply to US-
based operators.
Your assessment of the situation was wrong and deserved to be refuted.

Cheers,
  Tobi


___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] GDPR (equine corpse) (WAS: Re: The pool is shrinking)

[Tobias Mueller]

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
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: ... GDPR takedown request

[Tobias Mueller]

Hi,

On Wed, 2022-06-15 at 06:03 +0200, Kiss Gabor (Bitman) wrote:
> And moreover how will I do?
You can parse the file with, e.g., sequoia.

But you surely knew that you can parse the file, so I wonder what you're
trying to convey with your message.

Best,
  Tobi