Are there any efforts in writing a minimal version of it with a modern and flexible UI?
I imagine alternate pinentry implementations exist for other OSes as well.
Honestly the agent is better than it was (not that that's saying much). Other than that, GPG relies on one part-time developer - I'm sure contributions would be very welcome.
I have a key fob that performs cryptographic operations. Rather than use existing standards, GnuPG demands full control of the fob, making it impossible to use the same device for client certs on browsers, or for the VPN, etc. There are some barely maintained shims that get around some of these design flaws, but it's an extremely hassle to find the shims and to get them working.
GnuPG's agent also makes it quite difficult to use git remotely. Most of the code I write is on remote servers, setting up an agent to allow forwarded operations.
I think that it's time to move on from GPG, or fork it, or something. There's not much in GPG's implementation of PGP that I like.
It's the only mature implementation of the relevant standards (at least now that RSA inc. has demonstrated its nontrustworthiness). I've never known anyone have a bad word to say about the actual cryptography (and notably it seems to have been effective for e.g. Snowden).
By all means improve the agents and the integrations, and fork it if you think that will help. But keep the OpenPGP standard and keep the proven cryptography implementation. That part is worth its weight in gold.
Unfortunately after reading the source code and then reading the OpenPGP spec, I am convinced that most of the problem is actually OpenPGP. GPG is a bit of a hairball of a program, but it is faithfully doing what it is supposed to be doing.
Here is how I would describe the basics. Hopefully it will help you wrap your head around it. The bad part is that OpenPGP does not actually work this way. Consider this as "this is a way to view how it would work if OpenPGP wasn't completely insane":
- A key is composed of a private and public part. These are often referred to as "public key" and "private key"
- A key that one signs should actually be thought of as a certificate
- A certificate is just a bundle that includes a public key part, an "identity" (which is usually just a string, but can also include a picture), and a bunch of signatures. The signatures indicate that somebody believes that the identity is bound to the public key part (i.e. the string identifies the person who holds the private part of the public key).
- When you "sign" something, your signature is related to a piece of data (usually text). If someone has your public key part, they can verify only someone with the private part could have produced the signature. It is important to realise that you must sign something.
- When you "sign a key", what you are really doing is creating a signature for the identity string on a certificate and adding your signature to it.
- There are "master keys" and "sub keys". A "master key" should really be thought of as a certificate along with the private key part. A "sub key" is a public-private key pair with a particular ability (sign, certify, encrypt, or authenticate).
- You can create a certificate for your subkey that contains the public part of the subkey and is "certified" (basically signed) by the master key private part. This allows people to tell that your "sub key" certificate is associated with your "master key" certificate.
- Your sub key certificate has no identity information and is not signed by anyone other than the owner. To find out the identity of the person who owns the sub key, you have to have the master key in your possession and check the signature on the sub key.
- GPG makes a kind of "container" where it stores the master key certificate (which includes the public key part, the identity string (and possibly picture), and signatures of the identity by other people) along with the sub key certificates (which contains the public key part and a signature from they master key). In another place, GPG stores the private key parts that you may have for any master or sub keys.
Now go back to the GPG documentation and read it. That is how OpenPGP specifies that you must actually implement it. It would be nice to write an implementation that was simpler (possibly as I describe above), but it will always be a slightly leaky abstraction. And even my (much, much less confusing IMHO) description above is still ridiculously complicated.
Anyway, I hope you found it interesting.
I can't understand what people find to be so bad in it. It took half an hour to learn the basic usage and the commands aren't hard to remember at all.
Can you please elaborate?
You want this as a library that's impossible to misuse and a nice CLI on top.
The fact that it took you half an hour to understand the "basic usage" is ridiculous. The GPG developers have failed in the worst possible way when it comes to the design of their software. It's so bad I find it incomprehensible how that could have happened on accident.
If they would be working on something non-cryptographic, that would be one thing but for a cryptographic tool that's unacceptable. The design and ease of use is just as important as the cryptographic algorithms themselves for such a tool because any friction causes people to avoid cryptography.
What about distributing your key?
What about backing up your secret keys on paper?
What about binding your primary secure key that is usually stored in a safe on a Yubikey with secondary keys stored on Yubikeys you carry around with you?
What about revoking a secondary key after a laptop or Yubikey got stolen?
Perhaps you see where I'm going with this :)
The problem domain is just complex.
You need key rotation if you want security, so you need master keys and subkeys (or you'll end up reimplementing them by hand with conventions that everyone will interpret differently). Multiple identities on a key are I guess not strictly necessary but they're a very useful feature. You absolutely need the ability to sign other people's identities. You need to be able to sign and encrypt both text and binary (and do symmetric encryption), and export the result of everything in both text and binary. Smartcard support is a very good idea. Agent support is vital. What things do you think GPG should cut?
> You want this as a library that's impossible to misuse and a nice CLI on top.
Agreed. A rock-solid OpenPGP library would be great. I do think that's one place where there's a lot of real room for improvement.
> The fact that it took you half an hour to understand the "basic usage" is ridiculous. The GPG developers have failed in the worst possible way when it comes to the design of their software. It's so bad I find it incomprehensible how that could have happened on accident.
IIRC: developer, singular, unpaid and part-time. Also GPG is 20+ years old and doesn't want to change the CLI radically so as a) not to disrupt existing users b) not to disrupt existing scripts.
A frontend or alternative with great UX would be really useful. But who's going to pay for that work?
This same attitude may also explain the tendency to reinvent things like rsync and other tools that have accumulated a large set of options over the years.
GPG's particular command-line interface is still a counterintuitive mishmash of stuff that essentially boils down to having to look up a tutorial every single time I want to do anything related to key management. I've actually been known to ask people to email me just so I can fire up a mail client with Enigmail and have it auto-fetch the key into my keyring and set trust on it through their interface. Which, while not great, is light-years better than GPG's native key-editing interface.
Regardless, just like any feature-rich technical library, this is easily solved by a front-end. For example,
> Enigmail
...is an outstanding front end for many common uses. Unfortunately, the idea of writing a better UI front end for GPG - possibly many, specialized for various tasks - just like we've done for every other complicated piece of technology, it seems like everyone says "it's too complicated" and writes off GPG entirely.
> native key-editing interface
While I agree that interface is not the best (use Enigmail), I don't necessarily find it hard. It's very unrefined, tedious, and can be very annoying.
This is the same as saying "hard".
Note that GPG is not a technical library. The primary "library" for using GPG consists of some functions that system() out to GPG and pipe data back and forth. I think this is a big impediment to getting better frontends (particularly on platforms other than linuxlike desktops).