If you encrypt, you are probably familiar with Pretty Good Privacy (PGP) [1] or its clone GNU Privacy Guard (GPG). Most likely, you have used one of these tools to generate public and private keys and to encrypt email and files. The Free Software Foundation explains these tools in its Email Self-Defense Guide as a first step towards privacy [2]. However, despite PGP and GPS being ubiquitous when it comes to privacy, some people believe that these tools are counter-productive and little more effective than the feeble default protection available for PDF files when it comes to modern computing. Ironically, as PGP and GPG become more widely used, some security experts are advocating for their replacement with Actual Good Encryption (age), at least for file encryption [3].

Why do some security experts claim that PGP and GPG are obsolete? To begin with, PGP and GPG have long public keys that can be difficult to work with when space is limited, and copying them accurately by hand is difficult. In particular, they can be difficult to configure, even when the simple configuration wizard is used (Figure 1). When generating a key, PGP and GPG require numerous choices, including the encryption method, the key size, and how long the key is valid. Even a moderately skilled user can be hard-pressed to answer such questions intelligently. As a result, users may simply fall back on the defaults, although ignorance and security are hardly compatible. Many users, too, complain about having to move the cursor around to generate sufficient randomness – and, the longer the key, the longer it takes to generate the randomness. To further add to the confusion, PGP and GPG do too many things, such as signing services and key management, that many users have no interest in, which can add to the confusion.

Figure 1: PGP can be difficult for non-cryptographers to configure intelligently.

Even more important, PGP and GPG were first written in 1991, and they are showing their age. They come from an era in which cryptography was in its infancy. The Latacora corporate blog [4] complains about the "absurd complexity" that includes eight different ways of encoding the length of a packet and three different compression formats, as well as "keys and subkeys. Key IDs and key servers and key signatures. Sign-only and encrypt-only. Multiple 'key rings'. Revocation certificates." Likening PGP and GPG to a Swiss army knife that has multiple functions but does few of them well, the blog states baldly, "No competent crypto engineer would design a system that looked like PGP today, nor tolerate most of its defects in any other design. Serious cryptographers have largely given up on PGP and don't spend much time publishing on it anymore (…). Well-understood problems in PGP have gone unaddressed for over a decade because of this." Because of all these problems, PGP and GPG most likely lack what cryptography experts called "forward secrecy" – the ability to function today in the way in which they were originally intended. In fact, John Hopkins cryptographer Matthew Green declared as early as 2014 that "It's time for PGP to die" [5].

Age is designed as a partial replacement for PGP and GPG. It is not a complete replacement, because it lacks a wizard and does not manage keyrings or many other aspects of encryption. Rather, in keeping with the Unix philosophy that a command should do one thing very well, age only creates keys and encrypts files. Age offers a few other advantages:

• Functions are kept simple by using only default configurations
• Small keys
• No configuration options to understand
• Public and private key pairs and passwords, with multiple recipients
• The option for encrypted identity files
• Encryption via PEM-encoded, ASCII-armored format (the current industry standard) [6]
• Encryption for SSH keys, including GitHub .keys support

The result is a simpler, easier to understand approach to encryption that meets the highest modern standards.

Using Age

Age is available in most modern distributions. Compared to PGP, it is radically simple, with no options for key size or choice of algorithms (Figure 2). Before using age, all you must do is create a public and private key. The keys can be stored in a plain text file, but you should, of course, add a passphrase to the file, or else you have compromised the keys from the beginning. To do this, enter:

age-keygen | age -p > KEY-FILE.age

Figure 2: In contrast to PGP, age only needs to be configured by generating public and private keys.

If you choose an auto-generated passphrase, age provides an xkcd-style passphrase [7] consisting of a series of randomly generated words, which is easier to remember than a random set of upper and lowercase letters, numerals, and special characters.

Each file to encrypt can be given its own xkcd-style passphrase. However, to avoid unnecessary complication, you only reference the file that the key is stored in. To add the key for a recipient who has your public key, the file to be encrypted, and the name of the output file, enter:

age -r RECIPIENT-KEY INPUT-FILE OUTPUT-FILE.age

All these elements must be present for the command to function. To send to more than one recipient, add multiple -r options or else store a list of recipients in a file and add the path to the file using the -R option if you are using a recent version of age. Note that the -R option may not be available in some distributions' repositories.

Similarly, to decrypt a file, enter:

age -d -i KEY-FILE.txt -o OUTPUT-FILE ENCRYPTED-FILE

Age does not support ssh-agent, but it does work with sh-rsa and ssh-ed25519 SSH public keys. Using curl and a key listed in a GitHub profile, age can also send an encrypted file to a GitHub user, as follows:

$ curl https://github.com/benjojo.keys | age -R - example.jpg > example.jpg.age

A Payload Without a Delivery System

In its current state, age might be compared to a missile, whose payload is ready, but whose delivery system is still in development. Age offers a simple and advanced means of encryption, but it remains largely unknown and unused. This state of affairs is very obvious: When you make a mistake, age responds with "Did age not do what you expected? Could an error be more useful? Tell us: https://filippo.io/age/report." Moreover, current documentation is minimal, and age leaves the location of key files and the entry of recipients up to users to decide. In addition, it does not yet provide any key management.

Another obstacle to age's adoption is that while its advantages are well-known to many cryptographers, desktop and distribution developers are still focused on making PGP accessible to average users. This basic disconnect among developers still needs to be bridged.

For this reason, if you choose to use age, you need to be prepared to work out the delivery system by yourself. While not difficult, this approach is a little rough and ready, so if you want modern and secure encryption, be prepared. When using age, you are using a command still in rapid development.