I think a perhaps unclear part of the recent post "The PGP Problem" is that PGP is bad for email.
If you don't use it for email, I don't see it as really a problem. Unless, maybe, you are a reporter or otherwise not clear on the principles behind using something like GPG. I think personally that the point about all the discussion is that for laypeople PGP and email is just too complicated (even for myself as a programmer and evidently for others it is complicated).
In that same vein, I can see how PGP has fundamental limitations with email, e.g.: Having someone's email address does not imply that you have their public key. Is it possible to state in simple terms whether OP's program does to improve this?
> I think a perhaps unclear part of the recent post "The PGP Problem" is that PGP is bad for email. If you don't use it for email, I don't see it as really a problem.
You're apparently asserting that Latacora's "The PGP Problem" states PGP is only bad for email. I can only assume you didn't even bother the article? Because it states that PGP is bad:
* period and in its entirety, in fact most of the article (section 1 "The Problems") is the various ways PGP and GnuPG are broken at the core, specific scenarios are only mentioned (in section 2 "The Answers") to provide alternatives, because Latacora's assertion is that in cryptography one size does not fit all, and each scenario needs its own toolset
* for securing messenging
* for securing email messages
* for signing files and packages
* for encrypting files, whether to send, backups, application data, …
What it does state with respect to email is that encrypting emails is a fool's errand not just that using PGP to do so is a mistake. It does note that GnuPG is also specifically bad at it, but very clearly state the issue is not limited to PGP:
> This isn’t going to get fixed. To make actually-secure email, you’d have to tunnel another protocol over email (you’d still be conceding traffic analysis attacks). At that point, why bother pretending?
> Encrypting email is asking for a calamity. Recommending email encryption to at-risk users is malpractice.
So what's the alternative, for asymmetrically encrypting arbitrary binary data?
For sending such data to others, the Latacora article suggest a tool that I've never heard of or heard recommended by other experts called "Magic Wormhole". It's a new tool that (from what I call tell) has a whole crapload of limitations and assumptions that PGP does not have: https://magic-wormhole.readthedocs.io/en/latest/welcome.html...
One of the most severe is that it apparently requires both ends to have active internet connections to transfer the data over the wire between them. As I type this, I'm visiting my parents who have 5 Mbps internet. Let's hope that file isn't big or my contact has the time and patience to wait if it is! The other is that it apparently relies on a shared password, which just takes us back to encryption before the very problem PGP was designed to solve...
For simply "encrypting files", even Latacora gives up and says "use PGP"!!
As a side note, though I agree with them that PGP is not good for secure messaging, I don't find their alternatives convincing there either. Signal and Wire don't have solid group chat capabilities that don't rely on a single central server run by a third party and don't require private information like a phone number to use. I consider that absolutely basic for a good messenger. At least PGP, though very faulty in this area, is designed to be used over existing protocols like email to make them secure, so it doesn't have the last two limitations.
Wormhole isn't new, and if you haven't heard another "expert" recommend it, you don't hang out with a lot of cryptography engineers.
The point about "simply encrypting files" is that nobody is implementing something with PGP's "encrypt-a-file" interface because it's not that useful; rather, people purposefully design modern systems with cryptography tailored to tasks, like messaging or file transfer or backup.
Your last point about PGP vs. Signal is pretty funny, as it implies that PGP has "solid group chat capabilities".
> Wormhole isn't new, and if you haven't heard another "expert" recommend it, you don't hang out with a lot of cryptography engineers.
You're right, I don't. But the earliest thing I found about Wormhole after a quick look was from 2015, which I think is pretty recent in the crypto world. Maybe I missed something.
> Your last point about PGP vs. Signal is pretty funny, as it implies that PGP has "solid group chat capabilities".
I tried to be clear about the fact that I wasn't saying that. Its benefits over Signal and Wire (but not Matrix) are that it doesn't require a central server and doesn't require any PII to sign up. I consider those crucial for anyone who has extreme security / privacy needs. PGP completely sucks for group messaging, I agree. But the alternatives suggested are simply non-starters for many use cases.
Maybe? It depends on your requirements. Don't most experts recommend extreme caution with cryptography approaches and software that's less than a decade old? Has that changed? Do we move fast and break things now too?
Would also like to hear your thoughts on why / whether Signal and Wire are actually good recommendations.
I'll tell you what I don't understand. I don't expect random engineers on HN to be especially crypto-literate, nor should they be: it's a super-specialized field that demands a lot of spare storage capacity in your brain, and a lot of us had enough algebra after Algebra II in 10th grade. Engineers who specialize have a whole huge variety of things to pick: machine learning, distributed systems, optimization, network algorithmics, graphics, systems security, you name it. There's no reason a significant number of people here should have to know what Noise or SPAKE2 is.
What's weird is: if you don't know what any of this stuff is, why would you feel the need to express strong opinions about it? Is it really your belief that intuition and a drive-by reading of some slides on Github page can bring you up to speed with the field? I read every "Call Me Maybe" post and I absolutely do not think I'd have a chance in hell at getting a distributed commit protocol right. Hell: I "specialize" in cryptography and feel the same way about crypto protocols!
My thoughts about Signal and Wire are that I did a good job of relating in the post you're talking about what I think about Signal and Wire.
I'm not sure what this is in response to, actually. I'm not expressing any particular opinion about cryptography. I have no opinions and I defer to experts. One thing that I have heard experts say is that we should be very hesitant to use new protocols and software in areas in which a maximum of security is needed.
So I have no opinion of Wormhole, other than to say that (1) it is new, and experts I have listened to in the past say to be wary of new approaches, and (2) it (according to its own documentation) has some rather extreme limitations that make it arguably not a good fit as a general purpose solution to encrypted file transfer.
> My thoughts about Signal and Wire are that I did a good job of relating in the post you're talking about what I think about Signal and Wire.
As I don't think I have referred to any post by you, I don't know what you think about those solutions. If you are referring to the Latacora article (I think you wrote it, but I'm not sure because it doesn't specify its authors), it says (IMO) very little about the merits of Signal and Wire compared to other systems, and nothing at all about the specific criticisms I made in my comment you originally replied to.
Why do you keep nitpicking tiny aspects of what I'm trying to say? GPG sucks. Everyone agrees it sucks. The consensus of experts is that you should avoid it where possible. I have not denied any of that.
The problem is that some experts love to suggest alternatives that have severe limitations that GPG (for all its very real faults) does not have.
For 1 to 1 encrypted chats, I would trust Signal provided that OWS having my phone number (and that of my conversation partner) was not a security risk, and that I'm not facing a nation state level adversary who could take over OWS servers and push a compromised version of the app to me via update mechanisms.
In my opinion those are serious limitations that GPG does not have. And this is an area in which we're talking about the most developed alternatives (other than signing). Other areas like encrypted file transfer and group chat are even worse.
Regarding a secure group chat messenger with your two requirements mentioned, the consensus (among experts that have given their opinion here) seems to be that there is currently no such solution (I guess some versions of Wire could fit given that they seem to have on-premise deployment: https://wire.com/en/pricing/#pro/).
Thanks for the response. That matches my understanding of the situation. I'm not familiar with age, but I hope it turns into usable tool for some of these use cases, particularly asymmetric encryption.
Wire might eventually get there, but as far as I know they still haven't implemented federation, so (though I might be wrong) even their paid deployments would be limited to some particular network on which both conversants had accounts.
* 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.
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.
I guess what I don't see here is the case where (1) you can safely upload a .PGP file to Google Drive (or anywhere across the organization's network perimeter) without immediately triggering an investigation (PGP files being particularly easy to spot) and (2) you can't use Signal and Signal's built-in file transfer.
The opposite of what you're saying is true. File transfer is especially straightforward. Group chat on secure messengers works far better than it ever did with PGP. And, incidentally, there is no 10-year rule on cryptography.
Good! So what are the solutions? What file transfer approach
(1) Doesn't require an active connection between sender and receiver over the internet for the duration of the transfer
(2) Doesn't require a shared secret
What group chat secure messenger
(1) Doesn't rely on a central server operated by someone else
(2) Doesn't use PII as the basis of a user's identity
These are what I regard as the most basic of requirements for each need. PGP provides them (in broken, hard to use ways); others have struggled. If you actually do have solutions here, rather than just complaints about PGP, I do want to hear them. But you've taken this thread down a rabbit hole rather than respond to my original point, which was about the limitations of the suggested alternatives.
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.
By the way: why Signal/Wire/WhatsApp? (That being your earlier question):
* End-to-end encrypted by default, to the point that it's difficult to send plaintext.
* Radically simplified UX that doesn't meaningfully involve key management, which lawyers and activists cannot handle.
* By-default support for message log grooming / "disappearing messages".
* Modern cryptographic primitives.
* Extensively vetted cryptographic design.
* Works on phones, which are (1) the platform of choice for ordinary users, and (2) almost always more secure than desktop computers.
If you narrow the list down to Signal, you get to further add:
* Serverside privacy optimization / metadata minimization, so there's no targetable repository of all-pairs communicating parties, which is extremely valuable information for state-level adversaries.
* A commitment to not releasing features that don't square with those privacy objectives, so that for instance you can't share GIFs in the app until Moxie and his team figure out how to tunnel Giphy requests to foil traffic analysis, and you don't even get user profiles until a year or so ago, when Moxie and his team figure out how to provide them without generating a serverside database of identities.
* A multi-year track record of deep security auditing and a high-profile recipient of volunteer auditing unmatched by any other messenger.
I agree with your list of benefits. Only thing I really want to comment on (but see my response elsewhere) is
> My interest in strong privacy engineering means, frankly, I don't give a shit about federation.
I think the point of federation is that I don't know any way to get all three of the following:
1. I can run my own server, and keep my own account on it. (Last I checked, Signal couldn't realistically do that, but maybe things have changed or I was mistaken.)
2. I can communicate with one of my sources without them having to sign up for an account on my server (which may not be possible in certain conditions).
3. The protocol is not federated.
But maybe we mean slightly different things by federation.
Anyway, I'm sorry you've been targeted by people overly enthusiastic about the merits of PGP. I'm certainly not one - it's absolutely a very flawed approach.
I can see the case for a central server w.r.t. matching conversation pairs.
My objection is this: Signal (and others) seem to only support smartphone clients well. There's a genuine use-case for a more advanced user who wants to control every aspect of the platform he is using, including exactly when and what packets are being sent to whom. More importantly, the user may not want to process data on a von Neumann machine designed & administered by Apple/Google/Samsung. It would be nice if there were a supported command line interface, where the plaintext & encryption aspect of the protocol were handled separately from the ciphertext network traffic.
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".
My understanding is quite different. Email is inherently insecure and there is nothing you can do about it.
PGP is insecure for everything else as well
The Latacora article was eye-opening for me on the email problem - quite simply if I send an encrypted mail to a friend / collegue - which I intend them to read, and they read it and quote it to someone else in plain text then that's it - my plaintext and my cipher are available in the wild and my key (my long term key) is effectively broken.
I simply never thought it through that way. But that's how email is supposed to be used - it will be used that way.
I finally got that when someone pointed out that the long term key is not used to encrypt the mail content - i made that leap incorrectly and went from there.
I made the change down thread - was too late to edit the original - and i hope clearly pointed out that your article did not say that
It takes me several run ups to understand most security issues and I got all excited before having my coffee that day.
How do I negotiate a session key with the email recipient? it's a single transmission? otherwise it's a one time pad perhaps - but then that defeats the point of the public key ?
would you mind expanding on this as it is an interesting area
A random key is used to encrypt the email, then that random key is asymmetrically encrypted using the recipient's public RSA key. You do not use your own key to encrypt mails to someone else. Indeed, you can send encrypted emails without even having a key of your own.
And yes thats what he says in the original latacora post.
I read the article '''invariably CC the quoted plaintext of your encrypted message to someone else (we don’t know a PGP email user who hasn’t seen this happen)'''
So I made the (incorrect) leap to pgp using the long term key to encrypt files. My bad.
But this does not fix the original point it seems - email is not going to be "secure" any time soon. But you can send encrypted files over email to people.
> my plaintext and my cipher are available in the wild and my key (my long term key) is effectively broken.
Wait a minute. I may have to read the Latacora article again but if we are dealing with ciphers where having a plaintext attack reveals the key, I think we're in a lot bigger trouble than I ever imagined. To be blunt I don't really believe it and it would take some explanation to convince me it's true.
Edit: OK, I think I see the problem. I believe the quote in the article is discussing the fact that the user happily quotes a message and doesn't re-encrypt it, meaning that you have accidentally leaked the plain text -- not that they key is known. So I think they are arguing that we should write apps so that it is impossible to copy the plaintext.
Since (as detailed in the reply chain) this is completely incorrect (PGP simply doesn't have this vulnerability), can you edit the comment to that effect? Otherwise this claim is a bit dangerous.
Exactly. The "PGP is bad because public key infrastructure management is hard" meme should please die already.
The idea of a dedicated package signing and encrypting tool detached from this problem is maybe not a bad idea in that regard, because it removes this stigma.
If you don't use it for email, I don't see it as really a problem. Unless, maybe, you are a reporter or otherwise not clear on the principles behind using something like GPG. I think personally that the point about all the discussion is that for laypeople PGP and email is just too complicated (even for myself as a programmer and evidently for others it is complicated).
In that same vein, I can see how PGP has fundamental limitations with email, e.g.: Having someone's email address does not imply that you have their public key. Is it possible to state in simple terms whether OP's program does to improve this?