Opmsg – A GPG Alternative

I'm sorry for being snippy this morning. Read the /r/linux response to the PGP post to get an idea of what my baseline assumptions are about technologist disengaged with cryptography who have strong opinions about which cryptosystems people should use. But I shouldn't be projecting that on random people on HN, and I apologize for doing that to you.

My take is this (unless otherwise stated, "you" is the rhetorical "you", not you specifically):

1. PGP is bad and should be disfavored. Moreover, for some of its use cases, most especially "secure email", PGP flat-out doesn't work, and people need to be warned away from it. Most users will never see this HN thread and are getting their advice third- or fourth-hand. It's important that the "source" node for game-of-telephone graph have clear, sound advice. "Stop using PGP ASAP" is the most responsible advice I can offer.

2. The mainstream modern secure messengers are better than anything else technologists have provided to end users. If you're protecting serious things --- and the PGP team certainly claims to be doing that, so when you dip into conversations about PGP and its alternatives, you need to keep in mind that you're dipping into a game of telephone that ends with dissidents in countries like Venezuela where there are death squads --- Signal or something like it is the best you're going to do. You can be annoyed by this, and you're entitled to your opinion, but not to your own facts.

3. Nerds (I am one of those, btw) generally want something that (1) doesn't bootstrap off phone numbers and (2) lets people run their own servers. My interest in strong privacy engineering means, frankly, I don't give a shit about federation. I'm convinced that Moxie is right: federation means lowest-common-denominator protections; see Matrix, which has for years now been operating a network of off-by-default opt-in-only poorly-supported end-to-end encryption while at the same time being a darling of message board nerds. You don't have to disavow Matrix to be serious about security and privacy; I wish the project the best, too. But you can't be recommending it to immigration lawyers and foreign activists and demand to be taken seriously about security/privacy engineering (you didn't do that, but the modal "lol signal" nerd does), and I will strike down with great vengeance and furious anger anyone who tries to interpose themselves as an authoritative "source" of cryptographic advice and broadcasts to the world that Matrix is a reasonable option for those people.

4. I'm not a cryptographer, but one of my partners is, and I am myself a cryptographic vulnerability researcher (I'm comfortable assessing and breaking systems but wouldn't ask anyone to sign off on a system I designed). I feel pretty reasonably engaged with the cryptographic engineering community, which is extremely distinct from "people with strong opinions and affiliations with one or more well-known open source crypto-adjacent projects". It is "challenging" for me to hear things like (paraphrasing) "the experts I pay attention to say that you should wait a decade before using new cryptography". There is no such rule and, really, no way to escape the fact that if you're going to evaluate cryptosystems, you either need to develop the domain knowledge to do so based on intrinsic arguments, or enough domain knowledge to know whose recommendations are credible.

So my take is: I think you would have trouble coming up with a cryptography domain expert who will tell you our recommendations are "bad" (and, in fairness, one of the reasons that's the case is that our recommendations are vetted). Wormhole is fine --- pretty great, in fact. Be happy there's a system you can realistically use; it's good news. Ordinary people, like immigration lawyers, can't yet realistically use it, because it's a command line tool. I think that's going to change this year, but in the meantime, Signal does file transfers more safely than PGP does, so they should use that. Meanwhile, nerds like us can send files to people without keyservers and without giving up phone numbers. Or, if you don't have, like, access to the Internet, you can do something else.

> WhatsApp, Telegram and Signal use mobile phone numbers as identifiers

One notable exception (which as I understand is tptacek-approved) is Wire, which only needs an email.

Why do you want asymmetric file encryption?

* If it's to send messages to people, you want a forward-secure ratcheting secure messenger (regardless of your message lengths or the duration of conversations).

* If it's to back things up, you want a secure backup system like Tarsnap, and even if you don't, your system's sector-level symmetric encryption also does this. Asymmetric encryption is relatively high-risk! You don't want it unless you absolutely need it!

* If it's to send files to people, you want a secure file transfer system; you're not looking to transform the file itself, but rather to establish an end-to-end secure transport for the file.

* If it's to do secure package distribution, you want a simple file signing system, and OpenBSD already nailed this: it's called signify, and the portable compatible variant of it is minisign.

* If it's a component of an application you're designing, what you want is a library that encrypts blobs, not a program that encrypts files. Use libsodium.

I'm not denying that there are cases that don't fit any of these buckets, but I'd be interested in hearing what they specifically are.

I'm a lot less interested in hearing things like "sure I want a ratcheting secure messenger but I also want to run my own server" because that's not my point. I want a use case that fundamentally demands a standalone file encryption program, not a argumentum-ad-Rube-Goldberg for why you're duct taping something together with a file encryption program to accomplish backup or package distribution or whatever.

Look, my point is this: If I open my text editor and type some text, save the file and sign it with GPG with my private key to prove authorship, then I don't see how you are going to break this. In that specific sense GPG is not broken.

There are countless online puzzles or cryptography use cases based on this. I am asserting that since GPG is not broken in this specific sense, you can't just say GPG is broken "in its entirety".

Thank you for taking the time to give a thoughtful response, in this and your other comment. Here is what I take to be the use case - it concerns whistleblowers, who have among the most serious real world security needs.

I'm thinking of sending files to people. Large dumps of documents and other data from several GB to several TB. Imagine that any of the following apply:

* The data is in a secure location and can only be exfiltrated by the internet, not via a thumb drive. (And so my connection will be closely monitored.)

* The data needs to be sent to someone with whom I don't have another means of secure communication. In other words, I can't use symmetric encryption with a pre-shared key.

* I or my correspondent have slow or unreliable internet connections and maintaining a direct connection between each other would be difficult or impossible for the length of time needed to transfer the data.

* I or my correspondent are being closely monitored by the authorities, such that connecting directly to each other or using intermediaries that would allow us to do so is an unacceptable risk.

If any of these situations apply, I can't use Wormhole or similar approaches. I need something that will allow me to encrypt files for my correspondent without a shared secret, where I can upload those encrypted files to a service like Google Drive for them to download on their own time. This is precisely what PGP does.

I don't think it's unrealistic to imagine situations in which a source or journalist has one or more of these issues. I would very much like to see an alternative for use cases like this one. I'm in agreement with you that PGP is bad in many ways, from usability to the cryptographic implementation. But it's hard to deny that it's a remarkably robust solution to problems like this one.