Is there, right now, a better (security-wise and usability-wise) way to digitally authenticate a message (document/binary/payload)?
For modern message encryption, PGP is inferior to alternatives and generally should be avoided:
1. It lacks any native notion of forward secrecy or meaningful compromise recovery, which is table stakes for modern protocols.
2. Partly as a result of (1), it leaks meta-information; in particular, it's difficult to send deniable messages with it.
3. The most compatible subset of its protocols are built on 1990s cryptography, including non-AE bulk ciphers and RSA.
4. Its tooling is difficult to use, even more difficult to use with what we'd now consider adequate opsec, and far more difficult still for an ordinary person to use that way.
5. That tooling is of wildly variable quality; PGP sees somewhat routine vulnerabilities in its tools, which invariably get downplayed ("that's not a bug in PGP!").
6. Its most mainstream use is to attempt to layer modern message security on top of email, which is its own can of worms.
Generally, you should use Signal or maybe Wire (if you're a Signalphobe) in preference to PGP.
For an application where it really mattered, you'd want to see a signature system derived from SHA2 and Ed25519, with no backwards-compatibility towards archaic cryptography. There's nothing mainstream that really gives you this right now, but really there isn't much (outside of blockchainia, which is already hipster-deep in modern crypto esoterica) that really demands secure digital signatures.
That seems hard to believe unless I am misunderstanding you, because my experience is that any private key use requires auth from my Yubikey and yet I can do encryption without my yubikey plugged in at all.
edit: If by deniability you're talking about PFS, then, well, don't sign something you want to be able to deny having signed. I feel your comment might be misinterpreted to be a critique of PGP encryption when really it's a critique of PFS of PGP signatures+encryption.
So GnuPG to a degree makes it difficult to hide metadata about yourself as many tools will send your public key + data to a key server as soon as they create your key-pair. This is so when people verify you, your easier to find.
This creates a chicken-in-the-box metadata problem where for people to very your public GnuPG public-key is really you that info has to be public, but for anonymity it can't be .
> ...in particular, it's difficult to send deniable messages with it.
It's easy (unless tptacek is mentioning an attack I am unaware of) to ensure deniability -- encrypt but don't sign.
That's practically different than a system like OTR that has forward secrecy by default.
For me PGP is problematic in that the protocol itself is really confusing with a lot imprecise concepts. Even the definition of a "key": is it the private key part, the public part, the public/private pair, a certificate, or all of the above? For me, this is where a lot of people get in trouble. You need to understand exactly how PGP works in order to use it effectively.
I don't really see either of these problems being fixed any time soon, unfortunately (for me, anyway ;-) ).
What would you use it for?
Imagine I am a remote worker who does contract work. I have never met my employer. We want to agree to a contract and show that the information we're working from hasn't been compromised by someone from the outside. Ideally, I want to authenticate messages from my employer, and they want to authenticate messages from me.
It's important to realise that encryption is not necessary here. We just want to show that nobody is injecting requirements. If it gets down to a he-said, she-said argument, we want to be able to clearly show who said what. Second, identification of the parties is not necessary. I don't care who the employer actually is. I just care that they give me requirements and pay my invoices. Similarly, the employer doesn't need to care who I am. They just care that the banking information I send is really from me, for instance.
Now imagine that the employer doesn't know all the details of the project. They have other engineers who know the details. The employer refers me to that other engineer. Again, I don't care who the engineer is. I just care that they are the person that the employer referred me to. Importantly, I don't care who Google, or any other authentication agency thinks that engineer is, or what organisation Google thinks they work for. I care that the employer is satisfied that the engineer is the correct person to talk to. If there is a dispute, then it would be nice to show that I talked to the person the employer told me to talk to.
That's really all I want. To be honest, it shouldn't be that hard to implement. I think it's just that OpenPGP's implementation of WoT is so screwy that people just abandoned WoT without realising that it has use cases.
The example I gave is pretty ordinary, but you can probably imagine situations where one contact (that you don't know) wants to refer you to another contact (who you also don't know) and it's important that you are 100% sure that you are talking to the right person. In some cases, you want to make sure that nobody else is involved in the transaction, because it leaks information. In those cases a CA is really, really bad.
Edit: grammar
In your example, how did the remote worker discover the employer?
I won't argue the "there isn't much" part. That might be true. I will add trusted timestamps which were using hash chains before blockchains were invented. Surety is my goto example. Even they jumped on blockchain hype to score some money, though. (sighs)
https://en.wikipedia.org/wiki/Trusted_timestamping
Disclaimer: No affiliation with Surety or endorsement of them. They were just best example I know of company doing this for a long time.
Also, logs and accounting records. Some older papers I saw talking signatures were wanting to keep records from being tampered with over time. Those two are examples where strong, signature technology could come in handy. They mostly defaulted on paper and people, though. Probably a better choice given how computer security played out.
Maybe it is obsolete, maybe it isn't, maybe my tin foil hat is firmly in place. But it just seems like a thing people like to say to almost make sure other people don't bother trying it or using it.
Maybe that's because it's difficult to use, maybe it's because it works and does do things securely and some people don't want that.
There's so many sophisticated TLA's out there influencing 'the conversation' that who knows what to think anymore.
And it's increasingly odd to me. It makes sense to an extent, it lines up with a lot of what we already know about aligned interests, what happens when you challenge someone, etc. But at the same time, it's like the possibility of 'false flag'/Sybil/conversational manipulation is letting people double down on prior beliefs (which could in itself be the goal of the same level of "maybe everyone who disagrees with me is being manipulated").
Whether this is one of those means is unclear, but you're still probably better off using some form of free software for your encryption, and any encryption is still better than none.
This is news to me, but I'm not in "the Security Community". I can't find anything that corroborates this. Why do you say that?
What makes it ‘obsolete’ is that it lets you do bad things, like encryption without signing, messages can be partially encrypted/signed, etc. There are too many settings/options that amount to “change this to reduce security for no other benefit”.
The current ideal is software that is only capable of being secure no matter how you use it.
This also only applies to the algorithms that are currently considered not weak.
What is the target audience for GPG?
* Some package managers use it to sign binary packages. (Think apt-get)
* I personally use it in shell scripts to avoid storing some secrets in the clear on disk. (Use case similar to ssh-agent)
My own shell scripts are maybe more iffy, as I am not myself an expert, but my personal use doesn't see wide distribution.
Personally, I'm of the opinion that APIs should be as misuse-resistant as possible, and GPG is notoriously intransigent about actually acting as a well-designed API. Additionally, The Update Framework (TUF, https://theupdateframework.github.io/) prevents these issues by design.
Importantly though, it's a big project which in this specific instance meant that someone on earth did end up scrutinizing and publishing exactly the sort of thing you linked.
I uses GPG for encrypting files for the most part. I also use it for some of the situations where you might use ssh -- not because it's a good idea, but rather because I wanted to learn how to do it.
My main use for GPG, though, is for distributed authentication. PGP's web of trust is quite useful if you know how to use it. Very few people use it, because they don't know how -- and also PGP's protocol makes it very difficult to understand how to use it. On top of that, GPG's UI makes it even more difficult to use. But if you can wade through all that, it's fine :-)
The main scenarios where I think WoT is useful is where you have a historical relationship with someone and that relationship is more important that their actual identity. For example, maybe you exchange haikus with some guy that you don't know. They claim to to be Matsuo Basho, which you think is a bit fishy, but you just want to ensure that all of these haikus are from the same person claiming to be Matsuo Basho (and not someone pretending to be the person pretending to be Basho). Now if your Basho pretender wants to introduce you to their painter friend Claude Monet, you don't actually care if it's actually Claude Monet (you'd best be suspicious). However, when someone claiming to be Claude Monet contacts you, you want to be sure it's the same Claude Monet that your friend Basho recommended to you.
These are the kinds of scenarios where PGP implementations (like GPG) are pretty much the only way. You can do it by hand, but using GPG is very slightly easier. A more realistic scenario might be that someone is giving you requirements for some project and they want to delegate some of the specification duties to someone else on their team. You are a remote contractor and have never met any of the people involved. You are satisfied that your original specifier is valid because they keep paying your invoices, but you want to be sure that any other people you interact with are authorised to deal with you.
That means it's not fine. Footguns mean it's a non-starter. Also, you don't get to pick the algorithms when you're the recipient of the message.
I noted that the Snowden leaks said the NSA of all groups hated GPG since it blacked out their collection efforts. They had to send their limited team of hackers to deal with people doing that hitting other parts of their systems. If NSA isn't regularly breaking it, then it should be strong enough to stop all the threats likely to bother me. I push it plus a limited set of commands that make it easy, but annoying, to use. Instead of email, I just tell people to encrypt/sign text and zip files with boring names. That lets us dodge vulnerabilities that come from metadata, email interactions, and so on. Then, send them via whatever mechanism ranging from convenience to full anonymity.
Truth is I rarely use it because other people rarely communicate to me encrypted or request it. They usually send stuff to my Gmail account in plaintext or HTML. It's there if I need something stronger. It's a pain in the butt. I at least know it has a stronger baseline than most tools which are unknowns to me that I assume will get hacked until seeing evidence otherwise.
Not in banking anyway. It is widely used to protect ACH files and many other exchanges between banks (at least in the US).
For GnuPG there's an effort with NeoPG, although I don't know how it's regarded. Just heard the name and it is said to strive to resolve some GnuPG issues.
For OpenPGP itself, I don't think it's considered obsolete. I think there are fair concerns about OpenPGP-encrypted emails (when an alternative technology is an option), but I don't have the impression PGP itself is considered obsolete.
- It's hard to use for normal people, it's a lot easier to hand someone Signal
- It allows cipher suite changes, some of which may be weak
Basically, for the purposes you're talking about, ease of use isn't a major concern, but the second one is. A dead simple Ed25519-only signing tool would be viewed as better... does such a thing exist? Certainly it's fairly easy to create one using NaCl or even the reference implementation, but nothing has the popularity of GPG.
Deterministic key generation is one thing crypto has gotten right.
For basic signing and verifying purposes I believe Electrum and a few other clients actually include functionality for this which could be used as an alternative to PGP.
https://man.openbsd.org/signify.1
There's also a NIH version of this that I and a friend put together: https://github.com/ruuda/tako
This is overstated, and at the risk of tinfoil-hattery, I suspect that the NSA would very much like you to think that.
> I'm unclear for which of the many possible scenarios it can be used for.
It can be used for symmetric encryption, public-key encryption, and non-repudiable public-key signatures (analogous to signing a letter: you prove you signed it, but the recipient can publish that proof), with dedicated support for signing the identities of other keys ("web of trust").
Issues you may want to be aware of when using GPG in a security-critical context:
Do not use non-repudiable signing protocols for signatures that you want to be repudiable, obviously. For communications where you can rely on both being online (a much narrower niche than it gets presented as, IMO) there are ratchet-based protocols for notionally non-repudiable signatures ("off the record", intended to be analogous to a phone conversation: the other party can verify that it's you at the time, but doesn't get a signature they can publish in the future) which you might prefer, though I struggle to imagine any use case in which they give a real advantage (they mean there is no cryptographic proof that you signed the messages that were seen to come from you, but there will be as much proof as there is with an unencrypted email, which in practice is usually enough for even western courts, and would certainly be enough for despotic regimes rounding up rebels etc.)
Do not use obsolete algorithms (and GPG is rather more flexible about algorithm selection than it should be).
There is no good library for the GPG protocol, and wrapping the binary is error-prone. For e.g. email client plugins, make sure you're using a reputable codebase that has been subject to code review.
GPG's MAC construction is, while notionally sound, not as good as it should be. Where practical, avoid feeding input to GPG in an automated way and don't decrypt suspicious/unexpected messages.
Cryptographic best practice is to rotate in-use keys frequently; GPG offers you the tools to do this (subkeys) but does not automate their use. Ideally you should keep your master key in cold storage and use it only to sign subkeys, which you rotate in the same way you'd rotate e.g. HTTPS certificates.
While GPG has technical support for a "web of trust" it's not clear what signing a key should actually mean to a user. You should implement your own policies for which keys you trust, and be sure that anyone who you trust to attest to the validity of someone else's key is following a sufficiently stringent protocol before they sign things.
Encrypted email is of course still vulnerable to traffic analysis (and public keyservers by their nature publish even more information about who may be communicating with whom); when using the ascii-based format the subject field is also unencrypted.
> Is there, right now, a better (security-wise and usability-wise) way to digitally authenticate a message (document/binary/payload)?
Not really. The above list may sound intimidating, but it's around the edges: the core of GPG is as good as it gets, and I'd trust it more than anything from the present decade. HTTPS with client certificates is probably a little better audited if you can make the client/server arrangement fit your use case and you trust the 200-odd root certificate authorities.
There's no real reason to use GPG. Make an arbitrary scheme on top of something like NaCl and you'll probably be safer.
We'd often be wrong in such hopes, regardless of how good the underlying primitives are.
We should listen to the experts in that regard, and preferably use higher-level libraries written by the experts when performing common crypto operations. This stuff is easy to get wrong.
I'd welcome some full-fledged libgpg that would reliably implement gpg the executable's functionality, similar to e.g. libcurl vs. the curl executable.
For the record, I'm a Signal user and advocate.
We will undoubtedly have to integrate and access libraries like NaCl. But we should do so in keeping with best practices recommended by cryptographers (e.g. through NaCl's documentation), not by layering an arbitrary scheme on top.