> 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.
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.