PGP Security#
PGP has indeed become a mess1, and I have to admit that. It has integrated too many unnecessary features (which are actually historical baggage), is compatible with dangerous cryptographic primitives, and its excessive complexity has hindered implementation to the point that some programming languages cannot even provide sufficient libraries.
Certainly, I do not hope for PGP to fail before a fully inherited implementation of its goals appears, but it is also time to consider mitigating these issues. If I were to briefly discuss the mitigation of these issues:
Algorithms and Compatibility Quagmire#
Individuals can only mitigate this by agreeing to transfer keys to Curve 25519 (in fact, the latest gpg default settings already do this) - although the software may accept it, humans should not, or at least should not. The algorithm of the key itself is part of its trustworthiness. Perhaps gpg continues to provide various encryption primitives and curves, but it should strive to get rid of their outdated implementations as much as possible, for example, by providing warnings for outdated implementations (which is not enough at the moment).
Complexity of Data Packets#
This problem is unsolvable due to historical baggage, but considering the development of network transmission, as long as the specifications are sufficient, it is not a fatal issue in terms of security.
Excessive Features#
Actually, this is not necessarily fatal. The problem lies in the decoupling and implementation of various features. Since all features are bound to a set of key pairs, it provides a way to encrypt and sign with a shared identity, which is meaningful in itself. However, due to the complexity of compatibility and unified specifications, these features have more attack surfaces compared to dedicated systems. It is not possible to rely entirely on the perfect implementation of existing systems, so it may be necessary to introduce some kind of intermediate layer manually.
In other words, use the features of PGP to introduce other tools, while the actual work is done by other tools. For example, use PGP signatures as one of the channels for distributing minsign public keys.
The ultimate goal, of course, is to transition from the specifications to the introduction of new layers to replace the old features, although it is unlikely to happen...
User Experience#
Admittedly, PGP provides too many complex usage methods in its design, but it lacks a sufficiently simplified and comprehensive default configuration. This is largely due to the identity verification network (Web of Trust) envisioned by PGP, and the mutual signatures between key pairs and excessive metadata are remnants of this purpose.
But we must say that PGP has always been an additional security layer. Comparing it to a communication software or an encryption software is inappropriate because their simplifications are built on built-in security, but they do not address the overall problem and do not provide general functionality (although general and security are somewhat contradictory).
Command-line tools have always been intimidating, and GUI development has always been reluctant (at least I haven't seen a GUI that implements most of the GPG command-line functionality). In this regard, I found a relatively new implementation called GpgFrontend, unfortunately, its popularity reflects the predicament faced by PGP.
As far as I know, there are still various functional deficiencies in GUI support, such as lack of support for editing subkeys, incomplete key generation functionality, and customization of GPG path, homedir, and subkey export.
To fully implement the complex functionality provided by GPG without losing the simplicity of default configuration, this is a direction that needs to be developed.
Long-term Keys#
This is not crucial, or it is the most hopeless aspect in our common security thinking: everyone advises us to change passwords frequently, but this is impossible for users. Any secret that users directly use and remember cannot be changed frequently, this is a human problem.
The cost of enabling new keys should be minimized. This is a trust distribution issue, but it ultimately depends on user habits. Therefore, my suggestion is to use the expiration time of keys, not necessarily to actually expire them, but to assume that they may expire. Then evaluate the risks when renewing. Even so, it is necessary to ensure synchronization of distribution, which cannot be achieved by a single method.
Correspondingly, it should be insisted to remove expired keys. Do not retain all trust in them.
Inconsistent Identities#
It is a fact that there is no single possibility for identity distribution mechanisms. Now no one expects offline exchanges, existing key servers, and web of trust to provide all (or even most) of the trust. Encrypted identity schemes are just a basic ID: they cannot prove themselves. Now people need more identity proofs that span various network services, and in this regard, there are choices like Keyoxide, at least the ideas it provides are a possibility. The key points are:
-
We do use other network services. If you only use email for communication, you don't need a real online identity.
-
These services are not under our control. We cannot decide how they are represented, we can only support various specific methods.
-
Online identity itself can only be reduced to a way of connecting various contacts, and there is no real identity behind it.
Of course, it is also ready to abandon the original PGP method. It is ridiculous to put identity information in the comments of public keys. But the identity distribution system is undoubtedly not implemented, even though the specifications already exist, it has not been widely accepted in the ecosystem.
Metadata Leakage#
The uid metadata of PGP itself is visible, but this is part of its purpose. However, key servers obtaining metadata is the result of publicly exposing metadata information at a single level. Therefore, a better choice is to let PGP keys carry as little public information as possible and distribute them to other channels (such as the ideas of Keyoxide).
Lack of Forward Secrecy#
This should be noted. PGP should not directly exchange messages, but exchange one-time session keys (of course, it is unrealistic to require users to securely exchange them, there should be tools to achieve this). However, fixed encryption without forward secrecy for longer-term purposes cannot be abandoned: sending across time (laughs).
Clumsy Keys#
The legacy of the format, we can only hope that the improvement of the toolchain can improve it.
Negotiation#
If we have learned three important things about cryptographic design in the past 20 years, at least two of them are that negotiation and compatibility are demons. Defects in cryptographic systems often appear in the details, not the main structure, and the wide compatibility of cryptography increases the number of details.
Old versions must be deprecated resolutely, although the software may accept it, humans should not, or at least should not.
Poor Code#
GnuPG is also an effective reference implementation of PGP and the foundation of most other tools that integrate PGP encryption. It won't go anywhere, relying on PGP means relying on GPG.
What we are looking forward to is Sequoia-PGP, which may be the solution (or at least a mitigation) to the various problems mentioned above.
Web of Trust#
There have always been two ideas in the trust system. We have the authority-based CA system, but we also have the web of trust based on PGP. However, how to build a unified but reliable web of trust in current technology is an unsolved problem. In terms of software package trust, I just saw cargo-crev, but even in the developer community, it is still under investigation, let alone being as universal as CA certificates (but we all know the drawbacks of CA certificates: Last Chance to fix eIDAS: Secret EU law threatens Internet security).
Even though PGP has its shortcomings, its ideas cannot be abandoned. If we lose this decentralized trust, then Last Chance is not just about Europe, it's about browser certificates...