So I get the impression GnuPG is considered obsolete by the security community. I'm unclear for which of the many possible scenarios it can be used for.
Is there, right now, a better (security-wise and usability-wise) way to digitally authenticate a message (document/binary/payload)?
For simple operations like encrypting individual files or applying a signature to a document --- where the alternatives is already insecure --- PGP is fine, if clunky.
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.
I wish there was a more modern set of tools that implemented web of trust. I know that WoT will never be usable for the mainstream, but this does not mean that it is not useful at all. There are a lot of authentication situations where it is exactly what I want. Essentially the scenarios I want are: 1) I'm the guy you talked to last time and 2) I'm the guy that was talking to your friend. Having a central authority is inappropriate in a lot of cases, because the participants need to remain private (and it doesn't solve scenario #2).
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 ;-) ).
In another part of the thread, I kind of specified it a bit, but I'll try to give a realistic scenario here:
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.
"but really there isn't much (outside of blockchainia, which is already hipster-deep in modern crypto esoterica) that really demands secure digital signatures."
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)
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.
Can you elaborate on what you mean by (1-2) leaking meta-information and making deniability difficult? Do you mean that even when choosing to encrypt but not sign I am leaking definite proof (like a signature) of my private key information in the encrypted message?
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.
Your public key is always clear text, or at a minimum your public key finger print (which can be used via a key-server to find your personal information and public key).
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 .
This is all true, but is a different question from deniability when sending messages, and leaking metadata when sending information, which is what tptacek claimed:
> ...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.
Not sure what OP was getting at (maybe the difficulty of deniability using GPG/GPG-encrypted mail defaults), but you'd still be sending to a recipient's long-lived public key.
That's practically different than a system like OTR that has forward secrecy by default.
Since anyone in the world can encrypt to a PGP public key, deniability is trivial. It is true that some systems (like enigmail) also encrypt to your own public key when sending messages, but this is also easily deniable.
You usually want the recipient to be able to verify the sender, but not be able to prove it to a third party. Throwing away authentication entirely is a pretty baby-with-the-bathwater solution to deniability.
Well okay but he said "message encryption"; everyone is reading into that to mean authentication as well but I don't know why we should extend that understanding when a plain reading of his post implies a harsher critique of PGP encryption than warranted. It's also amusing how many people downvoted me for disagreeing with tptacek.
I'm beginning to wonder if this is an artificially created theme. In every discussion about GnuPG this type of thread begins and has this type of sentiment.
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.
I keep on seeing this sentiment of "TLAs/short-sellers/Russian content-bots/pick-a-boogeyman could possibly have an interest in this topic, so they're probably manipulating the conversation (conveniently against me and never in my favor). Who knows what to believe?, so I'm just going to continue believing what I believed before."
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").
It is odd, I agree. But on this specific topic I saw a) this weird tone shift seemingly overnight - while I really don't want to make this personal, a prominent individual adopting a quite different communication style to what they'd used before. And it came coupled with b) these inconsistent arguments that just don't make sense. Signal pushers smear those who disagree as "crypto nerds" and yet perfect forward secrecy, the one advantage their system has and the thing they use to argue for all the compromises they made in every other area, is the ultimate "crypto nerd" property: it's elegant and theoretically exciting but practically almost useless (I don't think I've ever seen a threat model where it actually makes sense).
We know the intelligence agencies have had an interest in this particular topic for a long time, and that they use a variety of means to discourage the use of encryption.
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.
Do you know what helps? Trying it out yourself and trusting your own judgement. To too many people nowadays, this is the first thing they abandon, while it should always be the last thing to be abandoned.
It's considered obsolete by the mainstream security community. Their prior recommendations often got hacked a lot, too. There's a niche group that promotes stuff that is stronger even if there's drawbacks to using it. We also let people decide if they accept those drawbacks. I'm in that crowd.
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.
The underlying crypto is fine (provided you don’t pick the weak algorithms) and use it correctly.
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.
The PBKDFs for symmetric (secring at rest and gpg -c) are also terrible. I'd love to be able to donate a few thousand dollars to a bounty to get this fixed.
What I meant was that the crypto primitives (the implementation of the math) is good enough for the application, the use/assembly of them (eg: the system) leaves much to be desired.
This also only applies to the algorithms that are currently considered not weak.
I am probably the target audience :-) Basically, to use GPG, you need to understand how it works. To understand that, you need to be quite technical and also willing to spend several days reading and thinking about what the implications are.
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.
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.
Thanks for that. I know that Debian has had security blunders in the past (RNG problems anyone?) so as I typed it I had some hunches, but...
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.
Thomas Ptacek, who is in the security community, expatiates on this in a sibling thread. It’s a good read, and I think it answers your question , which I didn’t know I shared :)
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 seems to me there's 2 reasons some people view it this way:
- 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.
Somewhat offtopic, but I'd love something like gnupg to support deterministic key generation, similar to what BIP39 did for crypto. I currently generate keys on an offline computer, back them up to a usb driver, and the copy the keys to yubikeys. It works, but it's a PITA, and I'm always worried that I'll lose my backups despite going through a lot of effort to keep them.
Deterministic key generation is one thing crypto has gotten right.
"crypto" is not short for "cryptocurrency", which is what I assume you mean. For many people it is short for "cryptography", and if read as such, makes your comment very confusing.
It's short for both at this point. The cryptography community doesn't get to dictate the meaning of ambiguous abbreviations, despite their frustrations. I agree that its confusing in context, though.
It's pretty handy, but doing it for RSA and other crypto systems which rely on large primes is much harder than doing it for crypto systems which can basically use random numbers with a few safety checks just due to the nature of key derivation functions. It is possible though, I seem to remember seeing a paper on it a while back and it should be entirely achievable to do something simple like seed the rng you use for generating RSA keys with an explicit value like that.
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.
> So I get the impression GnuPG is considered obsolete by the security community.
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.
I don't know for sure, but I think a lot of people who work professionally on messaging security would argue that NSA very much wants you to use PGP rather than a modern messaging cryptosystem.
Now, that is exactly what an NSA agent would say at this point in this conversation, to further dissuade people from using PGP! Tinfoil hats at the ready! :)
To further thicken the plot imo NSA and other TLAs are a red herring in a world where WhatsApp was acquired for ~20B. I don't believe for one sec that messaging app peddlers just want to make sure users' conversations are secure.
When WhatsApp was acquired, it didn't have meaningful cryptographic security. Facebook funded the integration of Signal protocol into WhatsApp after the acquisition. So there goes that theory.
Absolutely not. In fact, security was a differentiator for competing products when WhatsApp did not have it. Just not one people would care about. It fits nicely.
I feel like the whole "web of trust" thing failed, but otherwise, it's fine for signing things. Debian packages use it for that, for example (with a trusted way of bootstrapping the trusted keys).
Please, nobody who isn't a cryptographer (to be clear: I'm not one either) should be arbitrarily inventing schemes of combining cryptographic primitives and hoping they're secure in production use cases.
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.
Additionally, NaCl/libsodium is actually designed as a misuse-resistant API to perform real-world tasks, unlike GPG, where the API is "call this binary and use its crappy out-of-band signaling mechanism to figure out if anything went wrong".
This is what bugs me most about GnuPG - there's no real API, just an executable program with sometimes unreliable output. I mean, there is the GPGME library which wraps the executable calls in a C API (plus few other language bindings on the side), but it doesn't handle all the features the executable offers, often leaving you with a mix of GPGME API calls and "manual" calls to the gpg executable.
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.
Everyone would welcome it, but no-one's putting their money behind it. I suspect one of the real reasons that Signal uses a proprietary protocol (or rather, one of the real reasons that Signal was able to attract funding and improvements to GPG have not) is that having a locked-in userbase makes it easier to persuade VCs that there's a potential profit to be had. Whereas improving GPG would benefit everyone, but there's a tragedy of the commons around it.
I'm glad it's a good library. I was responding especially to "Make an arbitrary scheme on top of" whatever underpinnings one might choose, good or bad. That's not something we amateurs should ad lib where security matters.
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.
Is there, right now, a better (security-wise and usability-wise) way to digitally authenticate a message (document/binary/payload)?