41–50 of 197 posts
The suggested mitigation (editing `gpg.conf` and `dirmngr.conf`) doesn't seem to work for me. In particular I created `~/.gnupg/dirmngr.conf` with a line for the `keys.openpg.org` keyserver (and don't have a `~/.gnupg/gpg.conf`), but `gpg --refresh-keys` still uses `hkps://hkps.pool.sks-keyservers.net` which the gnupg Info (section 3.2 Dirmngr options) says is the default.
> 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…
[1] https://project-everest.github.io/
[2] https://www.fstar-lang.org/
Earlier quoted context omitted.
I’ve gotten stuck maintaining Python code for a testing framework and again for a CI/CD system. The fact that I know less than a junior programmer didn’t really slow me down that much, but it did make me a bit anxious. One of those systems involved a large and obvious crypto component. If the python code had been part of that work instead of merely peripheral to it, I would have rewritten it. Why? Because I can make…
I get that but in this case though this codebase has safety guarantees baked in via the Hindley–Milner (HM) type system whereas your python code base did not. Additionally there's a published, peer reviewed paper for this software that serves as a written specification. Those two things are fantastic resources when coming up to speed with an unfamiliar codebase.
Are you a maintainer or an armchair critic? I hope the latter, because if you think type safety is anything more than necessary but insufficient, then that’s number three.
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…
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,…
If people aren't adopting an objectively superior solution that currently exists and addresses all of the current use cases, that's an entirely different issue. I doubt that's the case here though.
I think (one of) the issues is that no one has yet managed to clearly define a set of goals that satisfy all current use cases while also addressing concerns about centralization, interoperability, and ease of implementation.
So why can't we deal with these types of attacks? IMO, the main reason is the the server code.
The author mentions that the sks keyserver is "written in an unusual programming language called OCaml", but IMO the language isn't the main issue. Here's a rundown of what I think the main issues are:
* Non-scalable database - SKS keyserver uses Berkeley DB as the database for storing keys, and bdb can't handle more than one connection at time. So, when huge keys with lots of spam signatures are being written to the database, it blocks all other transactions, including serving web requests (see issue #61[2]). The server needs to be re-written to use a database that can handle multiple connections (e.g. Postgres) so spam writes won't affect the web responses for unrelated keys. Unfortunately, the server is currently single-threaded and synchronous so it would have to be heavily re-written to add this kind of async scalability.
* Undocumented gossip protocol - The gossip protocol used is a very efficiency syncing algorithm that lets servers fill in the gaps for their databases from other servers. Unfortunately, the only documentation I can find on the gossip protocol is an academic paper[3]. This is a huge barrier for someone wanting to write a sks-compatible keyserver. You basically have to read the OCaml code (which doesn't have comments) to figure out how it works. For years I have wanted to try to write an alternative sks-compatible keyserver that could handle attacks like these better, but as it stands now, I'd have to spend a huge amount of time learning OCaml and reverse engineering the code just to understand how to write a compatible gossip implementation. Every once in a while I ask the mailing list for a mentor in helping teach me the gossip protocol[4], but so far either no one knows it or wants to teach it to me.
* Few validation and revocation features - OpenPGP is very flexible for how you can build public keys and signatures. I think there's a lot of creative things you can do with signature packets to let keyservers and public key owners clean spam out of their signatures. For example, OpenPGP signatures let you specify a "Signature Target"[5] in a signature, which could be used to let public key owners denote other signatures on their public key they wish to revoke, which the keyserver could then stop serving up to public requests. However, since the current server code is largely unmaintained, we can't implement some of these cleanup options.
Overall, I really love the idea of having a public, open, decentralized keyserver pool. Unfortunately, sks-keyserver wasn't written with much ability to scale (which was totally appropriate at the time), so it's in desperate need of being re-written. I'd love to do it, but simply haven't found the time to reverse engineer the gossip protocol. If someone out there wants to mentor me through it, I'd happily write an sks-compatible keyserver that could operate in the pool and also deal with these types of attacks.
[1]: https://sks.daylightpirates.org/ (currently down)
[2]: https://bitbucket.org/skskeyserver/sks-keyserver/issues/61/k...
[3]: http://ipsit.bu.edu/documents/ieee-it3-web.pdf
[4]: https://lists.nongnu.org/archive/html/sks-devel/2016-08/msg0...
Earlier quoted context omitted.
Probably OCaml. While it's been around much longer, it's never really reached mass acceptance (though does get used here and there). Rust is newer but I'd estimate it's already more used, and its adoption in industry is growing quite quickly. This is probably to do with the fact that OCaml doesn't necessarily solve any problems that are apparent to businesses, whereas Rust solves the very apparent "manual memory mana…
OCaml is very popular in academia though, especially in the field of theoretical computer science and formal verification. Coq, Frama-C, Flow, CompCert, etc are all written in OCaml. Heck, if you are running a graphical GNU distribution chances are that you have installed FFTW, which is written in OCaml. The "industry" is not the only thing that matters when considering the adoption of a language.
> 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…
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 completely synchronous, so you effectively have to cluster multiple keyservers running on different ports and different databases and load balance across them if you want to add any sort of scalability to your setup.
Overall, the server code feels like an MVP or academic implementation. Definitely not designed for high scale or the ability to handle abuse like this. It would take a heavy re-write to make get the server code to where it needs to be, which is why no one has stepped up yet.
BTW, I'd love to step up and write an sks-compatible keyserver in python (using postgres as the database), so that it could scale using something like uwsgi, but so far I haven't been able to find a mentor who can help me learn the gossip protocol that's largely undocumented.
[1]: https://bitbucket.org/skskeyserver/sks-keyserver/issues/61/k...
Isn't WKD supposed to help out with key distribution for email? * https://wiki.gnupg.org/WKD * https://tools.ietf.org/html/draft-koch-openpgp-webkey-servic... I'm thinking that's a better way to publish keys these days anyway. I have my own domain, so maybe OPENPGPKEY record in my domain as well DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP https://tools.ietf.org/html/rfc7929
It would be a better way, but the technology hinges on support by e-mail providers. I wouldn't recommend holding your breath. The other contender is Autocrypt, which performs key exchange inline in emails in an automated fashion. It only depends on client support, and has gained at least some traction (enigmail, k9, mailvelope, gpgOL, delta.chat, and some others).
Ah.
> The objective of the project was to develop new mechanisms for the reliable and automatic public PGP key exchange between e-mail providers. The results have also contributed to the WKS/WKD standard that is part of the GnuPG project.
https://mailbox.org/en/security
I was looking at going with mailbox.org or possibly protonmail (though they don't have calendars at the moment and I use that), both apparently support it. As does Thundebird+Enigmail, K9/OpenKeychain.
I have noticed the AutoCrypt method.
Part of the reason I changed my email is because I had in the past submitted a few keys to the sks network which I lost the private keys to, they were also submitted with an infinite expiry. I was a stupid kid.
So I am unlikely to submit my new keys to the sks network. Just store them in my domain, WKD, and on my blog.
[1] https://gist.github.com/rjhansen/f716c3ff4a7068b50f2d8896e54...