Age vs GPG #432

kotodharma · 2022-07-20T00:13:12Z

kotodharma
Jul 20, 2022

This looks like a very nice little tool, the sort I would like to adopt. I have a simple encryption workflow that I use on an almost daily basis, for which I've been using GnuPG with symmetric crypto (gpg -c) for many years. Can you "sell" me age for this and other basic crypto needs, elevator-pitch style? Although I'm willing to believe it is better than gpg in many ways, switching from a major project which is likely to survive to one which may or may not still be developed in 5 years presents a small risk. What are the marquis advantages? How about the security of the respective ciphers used? I'm a software dev and Gentoo Linux user who tries his best to be an armchair security wonk, although it's hard work :) Thanks.

cipriancraciun · 2022-07-20T06:45:07Z

cipriancraciun
Jul 20, 2022

[I am not an age developer, nor am I a cryptographer; however I am a long time GnuPG user, and follow closely age and other applied cryptography related subjects. Thus take my response as mainly a personal, somewhat informed, opinion.]

The main difference between GnuPG and Age is simplicity (or complexity if you will):

the file-format used is much simpler in Age than the one used by GnuPG (namely OpenPGP) which is quite complex because it has to support many use-cases and a lot of legacy; see RFC 4880 compared to age v1;
the cryptography suite is very "opinionated" in Age (a single algorithm per purpose, mainly ChaCha20 and Curve25519, both developed by Daniel J. Bernstein), while GnuPG (because it has to implement OpenPGP) it supports quite a wide range of algorithms (some of witch are not quite "modern" and might have weaknesses); thus when using GnuPG, especially with sensitive data, one has to be aware what actual algorithms are used;
(somewhat related to the previous point) the available cryptographic parameters (algorithms, strengths, rounds, key sizes, etc.) are chosen by the Age developers based on common best practices, meanwhile in GnuPG (due to the OpenPGP support) one can pick-and-choose (thus most likely due to not knowing the implications weakening the encryption) and the defaults are much more "conservative";
however, Age is a much younger design and implementation than GnuPG, which can be both an advantage (cleaner code, current best practices, current cryptography, etc.) but also a disadvantage (less reviews and audits that might have discovered potential issues;) (for example GnuPG tries to make sure that the cryptographic material, i.e. the secret key bytes, are not leaked to swap by using memory locking through mlock on Linux; searching Age's issues and code for mlock or secure memory or memory locking doesn't yield anything;)
one major advantage that GnuPG has (which keeps me personally trapped) is the existence of the gpg-agent that caches the secret key material so I can execute multiple encryptions / decryptions without providing the password multiple times (or using a password-less identity file);
obviously Age only supports encryption / decryption, but GnuPG supports also signatures; (for this use-case one could use minisign built in a similar manner to Age;)

Regarding your question related to the security of the Age's cipher suite, as said Age uses (based on the specification):

ChaCha20-Poly1305 (RFC 7539) (developed by D.J. Bernstein) -- used for encrypting the actual data (both for password based and private/public key modes);
X25519 (RFC 7748) (developed by D.J. Bernstein) -- used for private/public key encryption;
scrypt (RFC 7914) -- used for password derivation;
HKDF-SHA-256 (RFC 5869) -- used for various keys derivations (not passwords);

Thus all algorithms are RFC based (and as such at least sound for the purpose), and all are "modern" in the sense that the community doesn't recommend moving from them to better alternatives. (The only slight exception is perhaps scrypt where there is push towards Argon2.)

The other important observation is that both ChaCha20-Poly1305 and X25519 were developed by D.J. Berstein, and both of these seem to be the "favorite" ciphersuites for many current open-source projects. (Although cryptography is not a popularity contest.) :)

Have / will I switch from GnuPG to Age?

For the moment I've stayed with GnuPG. For a single use-case I've already used Age, and were it not for the #256 issue (i.e. the inability of reading passwords from a file-descriptor) I would have migrated more use-cases towards Age (including decrypting the secret key for disk-encryption on my personal laptop).

At the moment Age is missing some UX-critical features (at least for me):

it doesn't have an agent to cache the secret key material; (thus I'm left with repeated password entry or with password-less identity files;)
it doesn't support reading the password from a file-descriptor; (the password is still provided somewhow, but in case of early Linux boot that has to be through systemd-ask-password;)

Also I'm still waiting on the fence to see how Age develops further. The initial apeal of Age over GnuPG (at least for me) was the simplicity: one binary to do all it supports, no configuration files, no $HOME mandatory; in recent months I've seen quite a lot mentioned "plugins" in the Age discussions, thus I'm afraid the GnuPG complexity will seap back in through these "optional plugins". (In fact the password from file-descriptor is hinted to be implemented as a "plugin", which for an early system boot use-case seems too convoluted.)

This is how I view and feel about Age. As said in the beginning, take this only as a personal, somewhat (mis?-)informed opinion. :)

2 replies

kotodharma Jul 24, 2022
Author

Thank you, this is very helpful.

oscar230 Apr 7, 2023

Thank you!

samal-rasmussen · 2025-09-29T11:38:59Z

samal-rasmussen
Sep 29, 2025

Are there any performance benchmarks made comparing the two?

3 replies

cipriancraciun Oct 15, 2025

I don't believe performance is the best metric to assess an encryption tool, be it Age, GnuPG, or something else.

If performance is key, I would assume the amount of data is in GiBs, then perhaps one could use Age (or something else) to encrypt a strong symmetric password, and use a dedicated tool for the actual encryption. (For example one could ship a LUKS-encrypted raw image, or one could use something like aespipe or similar.)

However, if one just wants to benchmark the actual Age vs PGP encryption, things get complicated:

which Age implementation? The one in Go, or perhaps the Rust alternative? (one might be more optimized than another;)
which PGP implementation? GnuPG or Sequoia?
are you using a password or a private key? (because when using Age or PGP with a password, the key derivation function employs different parameters, and in case of PGP it's directly user controllable;) (for short payloads, the password derivation might be the bulk of the time spent;)
what CPU are you targeting? (Age uses Chacha20 which doesn't rely on special CPU instructions like AES does (which could be used by PGP); however if one uses AES without special CPU support, Chacha20 might be better;)
are you using Age / PGP as a library, or directly the CLI tool? (because, again for short messages, the OS overhead for starting and cleaning after the tool might be orders of magnitude more work than just the cryptographic code;)

As such, without a clear use-case in mind, benchmarking would almost certainly yield no useful information...

samal-rasmussen Oct 17, 2025

Thank you for the detailed reply. I didn't even know about Sequoia PGP.

Another factor to consider is how often you run the encryption. If it's not that often then the performance difference would have to be pretty huge in order to have any practical impact.

What I am thinking is that age as a narrower set of features and more modern and opinionated set of defaults. GnuPG and Sequoia PGP can be configured similarly as age defaults for a meaningful benchmark. This narrows the problem space considerably. And it would be interesting to run the benchmark on different size inputs.

I would find the initialization time for the cli versions to be kinda interesting to have in the benchmark results.

But yeah setting up a benchmark harness is always a lot of yak shaving.

cipriancraciun Oct 17, 2025

I would find the initialization time for the cli versions to be kinda interesting to have in the benchmark results.

Benchmarking that is hard without modifying the code to output detailed metrics, or profiling.

However, I can tell you from my personal experience that the startup time of Go applications is definitively more significant than for a Rust application, because in case of Rust, the only code that runs when the process starts (besides the minimal very low-level stuff required to interface with the OS) is the application's main, meanwhile in the case of Go (besides the same minimal low-level stuff) it also initializes (by running the init function, as per Go's spec) of every package that your application (or any of its dependencies) happens to reference (not necessarily use). (I've written more about this in this article.)

You can test this by running:

env GODEBUG=inittrace=1 age

Which yields:

init internal/bytealg @0 ms, 0 ms clock, 0 bytes, 0 allocs
init runtime @0.043 ms, 0.15 ms clock, 0 bytes, 0 allocs
init crypto/internal/fips140deps/cpu @0.51 ms, 0.006 ms clock, 0 bytes, 0 allocs
init math @0.56 ms, 0.007 ms clock, 0 bytes, 0 allocs
[...]
init crypto/x509 @2.3 ms, 0.001 ms clock, 48 bytes, 2 allocs
init golang.org/x/crypto/ssh @2.4 ms, 0.13 ms clock, 19848 bytes, 199 allocs
init main @2.5 ms, 0.047 ms clock, 32832 bytes, 3 allocs
[...]

Thus at least 2.5 ms are used to initialize some functionality that might get used.

Here is a benchmark between Age (Go) and Rage (Rust) (the same algorithm, just re-implemented):

## create 1 MiB of random data for encryption
dd if=/dev/urandom of=/tmp/message bs=1M count=1

## using armored output
hyperfine \
        --shell=none \
        --warmup=1000 --runs=1000 \
        'rage -e -a -r age1mulcx79t4tpte06xsxju2mjh48a37z5na2xrlpnhkpaqw8897qsshqht5l -o /dev/null -- /tmp/message' \
        'age -e -a -r age1mulcx79t4tpte06xsxju2mjh48a37z5na2xrlpnhkpaqw8897qsshqht5l -o /dev/null -- /tmp/message' \
#

## using raw output
hyperfine \
        --shell=none \
        --warmup=1000 --runs=1000 \
        'rage -e -r age1mulcx79t4tpte06xsxju2mjh48a37z5na2xrlpnhkpaqw8897qsshqht5l -o /dev/null -- /tmp/message' \
        'age -e -r age1mulcx79t4tpte06xsxju2mjh48a37z5na2xrlpnhkpaqw8897qsshqht5l -o /dev/null -- /tmp/message' \
#

On my laptop, they are almost neck-in-neck, thus it seems that at least for encryption use-cases, and for these implementations, there is no overhead. (Strangely, the Go implementation seems to be a bit faster.)

Comparing with GnuPG:

## using armored output
hyperfine \
        --shell=none \
        --warmup=1000 --runs=1000 \
        'age -e -a -r age1mulcx79t4tpte06xsxju2mjh48a37z5na2xrlpnhkpaqw8897qsshqht5l -o /dev/null -- /tmp/message' \
        'gpg -e -a --no-default-recipient --recipient user@example.com --output /dev/null /tmp/message' \
#

## using raw output
hyperfine \
        --shell=none \
        --warmup=1000 --runs=1000 \
        'age -e -r age1mulcx79t4tpte06xsxju2mjh48a37z5na2xrlpnhkpaqw8897qsshqht5l -o /dev/null -- /tmp/message' \
        'gpg -e --no-default-recipient --recipient user@example.com --output /dev/null /tmp/message' \
#

## here are the encryption parameters
gpg -e --no-default-recipient --recipient user@example.com --output - /tmp/message | gpg --list-packets

# off=0 ctb=84 tag=1 hlen=2 plen=94
:pubkey enc packet: version 3, algo 18, keyid {REDACTED}
        data: [263 bits]
        data: [392 bits]
# off=96 ctb=d4 tag=20 hlen=2 plen=0 partial new-ctb
:aead encrypted packet: cipher=9 aead=2 cb=16
        length: unknown
# off=117 ctb=ae tag=11 hlen=5 plen=1048589
:literal data packet:
        mode b (62), created 1760711474, name="message",
        raw data: 1048576 bytes

On my laptop, at least for armored output (the way I use it almost exclusively for portability), they are neck-in-neck. For raw output, age has a bit of advantage, however the difference is in terms of milliseconds...

Thus, based on this very unprofessional benchmark, I would say that both are fine in terms of performance.

gerowin · 2026-02-18T01:45:42Z

gerowin
Feb 18, 2026

This looks like a very nice little tool, the sort I would like to adopt. I have a simple encryption workflow that I use on an almost daily basis, for which I've been using GnuPG with symmetric crypto (gpg -c) for many years. Can you "sell" me age for this and other basic crypto needs, elevator-pitch style? Although I'm willing to believe it is better than gpg in many ways, switching from a major project which is likely to survive to one which may or may not still be developed in 5 years presents a small risk. What are the marquis advantages? How about the security of the respective ciphers used? I'm a software dev and Gentoo Linux user who tries his best to be an armchair security wonk, although it's hard work :) Thanks.

I am not a professional developer or cryptographer, just a tech and home-lab enthusiast, with some history in IT, who dabbles in scripts and personal projects on gitlab, so take anything I say with a very large grain of salt, and for exactly what it is, a personal preference that is subject to change should the software landscape evolve, or in light of new information.

I personally have "mostly" kept GPG/PGP around for two main reasons.

It's built right into Debian, and most other Linux distributions for that matter, so digitally signing things, encrypting things, etc. is made very easy with graphical utilities and extensions built into the user interface. In Gnome and KDE, once you create or import a PGP key, you can literally just right click a file and click "Encrypt" or "Sign" and perform either action entirely graphically without ever needing the terminal. You've got one key pair you can use for signing or encryption with the same utilities that come built right into most (all?) Linux operating systems right out of the box.
AGE doesn't, to my knowledge, support password protected key files. So any software running with user permissions can just read the plain text of your secret key file without any further verification or authentication from the user. There's no keychain front-end for AGE to manage key access, password protected key files, etc. Even SSH supports password protected key-files. Perhaps the folks that build utilities like Kleopatra or Seahorse should consider building support for tools like AGE and Minisign into their utilities so they can be managed and used easily right alongside GPG and SSH.

That said, I've started signing my git commits with my SSH key (ED25519) instead of my GPG key, and I have on a few occasions used AGE to do symmetric encryption of individual files or archives that I back up elsewhere. I use Signal for instant messaging, Wireguard for my home VPN, ChaCha20 for my password manager encryption, etc. I only use PGP to occasionally sign checksum files for releases of my personal projects on gitlab, to sign .deb packages of those same projects with debsigs, and by virtue of the fact my primary email address is ProtonMail, though it has its own key pair that I don't use anywhere outside of Proton. I even recently added Minisign signing to my build script for one of my personal git projects, on the off chance somebody doesn't like PGP and wants to verify the authenticity of a file, though debsigs doesn't support signing a .deb package with Minisign, so I'm only able to use Minisign to sign the checksums file I upload alongside everything else.

AGE is the newer tool, with two implementations (Go and Rust) that are more memory safe than PGP (built with C) with a lot less legacy nonsense to have to deal with purely for the sake of compatibility with some 30+ year old system that's using ancient and broken crypto. But, PGP/GPG is still built-into a LOT of things and does support modern algorithms; I migrated my personal PGP key to ECDH and EcDSA (curve 25519) a couple years ago, so at least from my non-expert standpoint, it's more accessible (for now) and appears to be secure enough for the very few things I actually use it for, with support for some modern algorithms.

1 reply

inferenceus Mar 2, 2026

@gerowin

AGE doesn't, to my knowledge, support password protected key files.

While age does not passphrase-protect identity files by default, it can be done via the following command: age-keygen | age -p > <identity file>

Age vs GPG #432

Uh oh!

Replies: 3 comments · 6 replies

Uh oh!

Uh oh!

kotodharma Jul 24, 2022 Author

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Replies: 3 comments 6 replies

kotodharma Jul 24, 2022
Author