Age File Encryption

Age is modern file encryption software that is small, fast and secure. In this blog post, I’ll go over some common encryption tasks that I have historically done using PGP, except I’ll be using Age instead.

Key Creation & Storage

Like other public key encryption tools, you have to be careful how you create and store Age keys. This is how I recommend Age keys be created.

$ age-keygen | age -p > /home/user/age/user.txt

You want to be sure that your private key is kept private, but you also need to ensure the key is accessible and backed-up in multiple places.

If you set a password on your private key and forget it, you will be locked out of your encrypted data.

I typically store private keys in /home/user with 400 permissions, back them up to encrypted USB sticks and to secure remote servers.

Private Key Passwords

Age allows users to password protect private keys but suggests that doing so is only useful in some scenarios (you plan to store the key remotely). I disagree with this advice. I always password protect my private keys. And I think that doing so is useful no matter where the key may be stored.

My computer could be stolen, hacked or confiscated by law enforcement. And no matter the scenario, I want all of my private keys to have unique, strong passwords.

And yes, I do use whole disk encryption, I do use gocryptfs, and other tools, to protect my data and privacy, but IMPO, every layer counts and it’s very important to have strong passwords on private keys no matter where they are stored.

The only exception I make to this is for automated processes that must decrypt data without any human interaction.

Age PKI Issues

While Age makes use of public key cryptography, the Age Specification does not address public key infrastructure issues (identity binding, key distribution, key revocation). That’s a complex problem and not something the Age designers intend to build into the software.

However, if you are going to use Age for file encryption in an organization, you need a way to discover keys, distribute them, rotate and revoke them.

I’m currently using TXT records in the DNS for these things. Here’s an example of getting a key for a specific user.

$ dig +short TXT brad.w8rbt.org | tr --delete \"
age1pzrt573f99lgr2p3enpycw50txpe25trj4467yw3a76k0k57cg5qsnwpek

The above command will obtain the Age public key for [email protected] from the DNS. A user can run dig manually or include dig in a script as part of a semi automated of fully automated process.

This approach assumes you control your DNS and your DNS has one public Age key per email address. So [email protected] would have an Age public key in a named DNS TXT record user.example.com.

If a key is no longer valid (for whatever reason) you can update the DNS TXT record for that key. And you should use short TTLs on the TXT records (say 5 minutes) so the DNS will update frequently.

Is the DNS safe enough to handle PKI?

We already trust our email and web presence to the DNS. I think it’s reasonable to also trust the DNS with public encryption key distribution and revocation. If your DNS is compromised, you’ll have a lot more to worry about than public key TXT records.

As the DNS becomes more secure and more private with technologies such as DoH, DoT, DNSSEC, DNSCurve and DNSCrypt we’ll be able to trust the DNS even more.

Environment Variables

If you only interact with a few individuals who use Age, you may decide it’s better to obtain their public keys directly and then set them as environment variables.

$ echo "export BOB_AGE_KEY=age1wwza0rfylltta098aksayaqdgaacdvj3ntydsmks8slar0p5lp6q93flrt" >> /home/user/.bashrc
$ echo "export ERIN_AGE_KEY=age1ly7ugncyxasmweu7rnjwl4ue6hjns277284rjn5tmg8kh26ce9fqrx845a" >> /home/user/.bashrc

After doing that, encryption could be accomplished like this.

$ echo -n "Message to Erin." | age -a -e -r $ERIN_AGE_KEY
-----BEGIN AGE ENCRYPTED FILE-----
YWdlLWVuY3J5cHRpb24ub3JnL3YxCi0+IFgyNTUxOSBpV3RsVktMZWpreFhrU2tR
anc4ZTVxVXpObGg2ZnJ5Nm1ZKytGTGJVano4CmVTVFF5WjhOM3dNWTFhWXhZRFFO
aXdLRmk4ZDNyNm1KelI1dFhoR0lzSGsKLS0tIEFIdzBQUDhhMkJXK0lZSlFlR0NN
U0RiZW9LTmlUZnhmZmtnaHN5ZERMSEkK5AUVdEUwYF+OEDPjco9tjKujbfJfTfGs
jcw3y1uQQ2vd3Vb2aJ+H6NQCWFI5cIyK
-----END AGE ENCRYPTED FILE-----

Email

The Age designers consider email to be a ‘fundamentally unsecurable medium’. However, it’s straight-forward to use Age to encrypt a file and then email that file to one or more recipients. Here’s one way to do that.

$ cat age-encrypt-and-email-file.sh
#!/bin/bash

file=$1
subject=$2

cat $file | \
age -a -e -r $(dig +short TXT brad.w8rbt.org | tr --delete \") | \
mutt -i - -s $subject [email protected]

The above bash script cats a file to stdout, pipes it to Age (which automatically gets the public key from the DNS), then encrypts the file to that key before finally piping the encrypted file to mutt (which sends the file in the body of an email).

Multiple Recipients

When sharing an encrypted file with someone, it’s always wise to encrypt the file to their public key and to your public key.

This feature is also useful for sharing sensitive files among teams with more than two members.

$ age -e -a -o file.txt.age \
-r $(dig +short TXT brad.w8rbt.org | tr --delete \") \
-r $(dig +short TXT ana.w8rbt.org | tr --delete \") \
-r $(dig +short TXT erin.w8rbt.org | tr --delete \") \
-r $(dig +short TXT bob.w8rbt.org | tr --delete \") \
file.txt

Then, each team member can individually decrypt the file.

$ age -i ana.txt -d file.txt.age
This is a test.

$ age -i erin.txt -d file.txt.age
This is a test.

$ age -i bob.txt -d file.txt.age
This is a test.

Additional Decryption Key (ADK)

ADK is a concept closely related to multiple recipients, except the intent is a bit different.

Say your organization requires strong encryption due to privacy laws or industry regulations, but the organization also requires that all data be accessible to management or the security team at all times.

Rather than share private keys or backdoor the encryption process somehow, the organization can require that all data be encrypted to an Additional Decryption Key (or multiple) during encryption. An ADK is just another public Age key.

ADK allows for organizational control and oversight of data while maintaining strong encryption practices.

In the example below, Tom encrypts a file to himself, to his teammate Ana and also to the security team’s public key so that the file can be inspected for malicious content or perhaps for inappropriate access (maybe Tom or Ana shouldn’t have access to the content in data.txt).

$ age -e -a -o data.txt.age \
-r $(dig +short TXT tom.w8rbt.org | tr --delete \") \
-r $(dig +short TXT ana.w8rbt.org | tr --delete \") \
-r $(dig +short TXT security.w8rbt.org | tr --delete \") \
data.txt

Now, all parties that need to access the encrypted file may do so, but no one else can.

$ age -d -i tom.txt data.txt.age
another test

$ age -d -i ana.txt data.txt.age
another test

$ age -d -i security.txt data.txt.age
another test

Is Age Better than PGP for file encryption?

For individuals, small technical teams and organizations, I think Age is really great. I recommend it. But, all the things I did above can be accomplished with PGP.

PGP is larger and more mature than Age and more widely used. PGP has an RFC as well as mechanisms for key distribution, revocation, email and many other things that Age ignores.

Age is simpler, smaller and more modern. Age keys are more compact than PGP keys, and thus easier to distribute in various ways.

Are the Age differences compelling enough to switch from PGP? I’m not sure.

Let me know what you think about Age in the comments below.

• encryption