Live data from Hacker News

SKS Keyserver Network Under Attack

gist.github.com

81–90 of 197 posts

Re: SKS Keyserver Network Under Attack

#81

Earlier quoted context omitted.

The idea of Internet actors (human or machine) owning cryptographic identities in a distributed system is a good one. I don't think we should stray from this approach. From your Matthew Green link: > If PGP went away, I estimate it would take the security community less than a year to entirely replace (the key bits of) the standard with something much better and modern. It would have modern crypto and authentication,…

It's not the silver bullet we need, but I really like Keybase's approach. I think any PGP replacement should take notes from their architecture.

It's not a silver bullet, but is it not better than PGP? Is it not good enough?

Re: SKS Keyserver Network Under Attack

#82
post #24

Earlier quoted context omitted.

https://rationalwiki.org/wiki/Argumentum_ad_hominem

That wasn't an argument... It was an expression of confusion as to why the author would say what they said.

It's not. This thing:

https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d695...

is not an 'expression of confusion', it's an attempt at offtopic shitstirring and mockery. It's kind of dumb in the gist - keeping it up on HN (where it's sensibly forbidden) is worse.

Re: SKS Keyserver Network Under Attack

#83

Earlier quoted context omitted.

It's not the silver bullet we need, but I really like Keybase's approach. I think any PGP replacement should take notes from their architecture.

It's not a silver bullet, but is it not better than PGP? Is it not good enough?

It's still too centralized. You and I can't run our own compatible public Keybase servers, or our own private servers. Understandable, as their investors expect them not to give away everything for free.

The client is open source so reverse engineering and improving the server architecture is far from impossible. I think Keybase is making great strides on exploring how we can utilize asymmetric E2E encryption for communication, organization, storage, and everything in between. I think they've made tremendous progress in making E2E cryptography accessible. However we need a 100% FOSS system.

See: https://github.com/keybase/client/issues/6374

Re: SKS Keyserver Network Under Attack

#84
post #45

I have maintained keyserver in the pool for many years[1], and attacks like this are, in theory, able to be easily mitigated. I mean, we're only talking about appending spam to public keys. It's not like the attackers found some flaw in OpenPGP that breaks public keys or valid signatures. In theory, all these attacks to do is cause bloat on keyservers. So why can't we deal with these types of attacks? IMO, the main r…

I don't think that the base issue lies in the implementation: you can make it as scalable, parallel and document as you wish, but if what you are doing is basically receive data from whoever sends you something, store it, pass it to other server and do not offer any form of accountability over who can store such data or who can delete it, it will always be trivial to write a script that just sends lots of data and bl…

Hmmmm, isn't that an inherent property of any for-public-use database? By your definition, any public pki (keybase.io, keys.openpgp.org, etc.), social network (Twitter, Facebook, Mastodon, etc.), and more are vulnerable to someone just writing a script and bloating their database.

What mitigation strategies do other ecosystems use? Why can't they be tried in the keyserver pool?

Re: SKS Keyserver Network Under Attack

#85
post #78
post #47

Earlier quoted context omitted.

> Any particular reason it's difficult to maintain (other than the lack of popularity of FP in general)? A much bigger issue than the language itself is the overall architecture of the server. It uses Berkeley DB as the main database and only handles one connection at a time. So, if your gossip process starts syncing a huge spam key, you block all front-end web requests (see my issue #61[1]). Also, the keyserver is c…

[deleted]

[deleted]

Re: SKS Keyserver Network Under Attack

#86
post #66

It's fascinating that the conversation in the GitHub comments went to both personal attacks on the author of the post and defending child pornography in the span of like five responses. I feel like part of the problem is that anyone who's skilled enough to implement solutions has better things to do with their time than participate in a discussion of that quality.

Hmm. Has a site ever experimented with separate comment sections? Put simply: on vs. Off topic (or maybe "meta") . Our comments would be in the off topic section, for example.

I regularly see people apologizing for being off topic. Clearly they have something they think is worth saying, but are afraid to pollute the discourse.

Re: SKS Keyserver Network Under Attack

#87
post #42
post #5

> It's written in an unusual programming language called OCaml, and in a fairly idiosyncratic dialect of it at that. This is of course no problem for a proof of concept meant to support a Ph.D thesis, but for software that's deployed in the field it makes maintenance quite difficult. Not only do we need to be bright enough to understand an algorithm that's literally someone's Ph.D thesis, but we need expertise in obs…

To the commenters blaming OCaml - it is being used in the Project Everest[1] (along with F#) for creating a proven network security stack. Basically, they created ML-like language called F*[2], which fits the task perfectly. There is also a pure OCaml implementation[3] of TLS stack, along with x509[4]. [1] https://project-everest.github.io/ [2] https://www.fstar-lang.org/ [3] https://github.com/mirleft/ocaml-tls [4]…

I believe they are using the C target/dialect of F* for Everest.

Re: SKS Keyserver Network Under Attack

#88

It's always sad to see someone taking down a project that is run with the best intentions. However, it may be time to move away from the entire PGP ecosystem. Consider the post's "We've known for a decade this attack is possible. It's now here and it's devastating.". Consider also the final section, "PGP is bad technology and it’s making a bad community", of https://blog.cryptographyengineering.com/2018/05/17/was-the…

> However, it may be time to move away from the entire PGP ecosystem.

To what exactly?

Re: SKS Keyserver Network Under Attack

#89

It's always sad to see someone taking down a project that is run with the best intentions. However, it may be time to move away from the entire PGP ecosystem. Consider the post's "We've known for a decade this attack is possible. It's now here and it's devastating.". Consider also the final section, "PGP is bad technology and it’s making a bad community", of https://blog.cryptographyengineering.com/2018/05/17/was-the…

I appreciate the sentiment; the wider ecosystem is a shite show. Consider that recent RHEL releases still don't come with an rpm version that supports subkey signing, and that it took something like 10-15+ years to get that added in after it was first brought up. Then, you have gpg forcing the agent down peoples throats turning a task that should involve a static binary to sign packages into a potential life altering event... The v1 to v2 changes and differences(like the dang agent) and timeline.

It's so embedded in stuff though, even if it feels jammed in and is half sticking out, I can't imagine it going away super soon.

Re: SKS Keyserver Network Under Attack

#90
post #51

Earlier quoted context omitted.

I don’t think the AUR has a concept of package signing—a PKGBULD will often download a tarball from somewhere and any signing is ad-hoc. The official repositories use their own key ring (which is distributed without a key server).

Correct. The only time when this would concern you is when you add a third-party repository, e.g. one of [1]. This usually involves a manual TOFU step where you do the equivalent of `gpg --recv-keys $ID` on the pacman keyring. [1] https://wiki.archlinux.org/index.php/Unofficial_user_reposit...

Beware that "gpg --recv-keys " (or even "gpg --recv-keys "!) can be tricked into inserting malicious keys into the keyring:

https://dev.gnupg.org/T3398

Post reply on HN