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 :)
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?