2026-10-30 - Encrypting files with age, post-quantum included: a practical guide and its limits
In my
article on how hard it is to get someone to send you an encrypted file
, I distinguished encrypting the channel from encrypting the document. This companion piece is about the latter: how to encrypt a file with age, including with post-quantum keys, and which limits to keep in mind. Information on versions and tools reflects the situation as verified on 25 October 2026, within the survey I carried out.
age in a few lines
age is a file encryption format and tool. It was designed by
together with
, as stated in the
, and its specification is published in
. The project states a few principles: small explicit keys, no configuration options, and composability with other command-line tools.
age encrypts the file’s content with ChaCha20-Poly1305, in 64 KiB chunks, using a key derived from a random file key; the file key is then “wrapped” separately for each recipient (
). Recipients can be X25519 keys, hybrid post-quantum keys, a passphrase or SSH keys.
The format has precise limits. It does not sign files and does not authenticate the sender: whoever receives a file cannot tell, from the file itself, who encrypted it (
Filippo Valsorda, age and Authenticated Encryption
). Moreover, the specification defines no key revocation mechanism and no trust model: verifying and replacing keys is left to the people who use them.
Why post-quantum is mainly about key exchange
The European roadmap for the transition to post-quantum cryptography describes cryptographically relevant quantum computers as machines able to solve the factorisation and discrete logarithm problems on which today’s public-key cryptography rests. It also notes that the notion of “quantum-safe” covers symmetric cryptography algorithms (
). The most exposed point is therefore key exchange, rather than the symmetric encryption of the content.
The risk is known as “store now, decrypt later”: encrypted data collected today could be decrypted in the future. The roadmap sets out recommended targets, not binding deadlines: national strategies started by the end of 2026, high-risk use cases transitioned by the end of 2030, medium-risk ones by 2035 and, as far as feasible, low-risk ones too.
On this front, since version 1.3.0, age offers hybrid keys combining ML-KEM-768 and X25519 (
). The
defines a hybrid as a combination whose security matches that of its stronger component. For this to hold, however, the combination has to be built correctly: age uses the MLKEM768-X25519 construction, also known as X-Wing, defined in its
.
First steps: generating a key and encrypting a file
The commands below are those documented in the
. Two notes before starting: you need age 1.3.0 or later; and of the two files created, key.txt contains the private key, to be kept safe, while recipient.txt contains the public key, to be shared.
To install age, follow the
. Then check the installed version:
age --version
Generate a post-quantum key pair and derive the public key to share:
age-keygen -pq -o key.txt age-keygen -y key.txt > recipient.txt
Post-quantum public keys start with age1pq1 and are about 2,000 characters long, so it is easier to save them in a file and pass them with -R than to paste them on the command line.
Encrypt a file for that recipient, and decrypt it:
age -R recipient.txt -o document.pdf.age document.pdf age -d -i key.txt -o document-decrypted.pdf document.pdf.age
When decrypting, it is wise to use a name different from the original: if the output file already exists, age overwrites it (
).
Inspect, without decrypting the file, the recipient types declared in its header:
age-inspect document.pdf.age
age-inspect reads the header: on its own, it does not verify the integrity of the content or whether the file can be decrypted (
).
After decryption: origin and content
A file encrypted with age does not, on its own, identify the sender or show that its content is harmless. Confidentiality, origin and harmlessness are different properties, to be checked separately.
Origin. A file encrypted to your key may come from anyone who knows that public key. For important documents, it is worth confirming the sending with the sender through an independent channel, such as a phone number you already have rather than one given in the message itself. A valid digital signature, where present, authenticates the origin against the verified key and protects the file’s integrity. Neither the confirmation nor the signature, however, guarantees that the content is harmless: even a genuine sender’s device can be compromised.
Content. Anti-malware filters that do not hold the key cannot inspect the content of an encrypted file: they can block the attachment or weigh other signals, and after decryption the device’s own protections can come into play. Ordinary decryption with age does not automatically open or run the resulting document. The format is a container for encrypted content, not an archive with file names or extraction paths, and the output file is chosen by whoever decrypts (
). The content can become dangerous when a program interprets it, even just to generate a preview or carry out automated processing. Sticking to expected formats, such as PDFs, images and documents without macros, reduces some attack possibilities without guaranteeing harmlessness; it is worth checking the file’s actual type and keeping up to date the programs that open it or display its preview.
For files you do not trust,
by the Freedom of the Press Foundation reduces the risk: it converts the document into pixels in an isolated environment and rebuilds a PDF without active content. The conversion alters the document and does not preserve any digital signatures, so for important documents the original should be kept separately. What to avoid, on the other hand, is uploading confidential documents to public analysis services such as VirusTotal: the contents of submitted files may be shared with the service’s premium customers (
), a disclosure that may prove incompatible with confidentiality and professional secrecy obligations.
One last caveat concerns AI: a document stripped of active content may still contain misleading instructions aimed at an assistant. The conversion does not replace the controls on the agent’s permissions described later on.
Multiple recipients, and one rule to know
A file can be encrypted to several recipients by repeating -r or -R. The typical case: the same document encrypted to several post-quantum recipients, each with its own private key, for instance one key on a computer and one on another device. Each opens it with its own key, and no private key has to be copied or shared.
age -R recipient-computer.txt -R recipient-other.txt -o document.pdf.age document.pdf
The rule: age refuses to mix post-quantum and classic recipients in the same file. If one of the recipients were a traditional X25519 key, the file would be exposed to quantum risk through that key; age prevents this and reports an error (
).
Hardware keys and the Secure Enclave
age 1.3.0 natively accepts two recipient types designed for keys held in hardware: age1tag1 (P-256 keys) and age1tagpq1 (hybrid P-256 + ML-KEM-768) (
). The age1tagpq1 recipient is also classified as post-quantum (
), so it can sit in the same file alongside age1pq1 keys.
One distinction is essential here:
- encrypting to these recipients requires no plugin: a recent version of age is enough;
- decrypting requires the matching plugin and the device that holds the key. On a Mac, for example, that means
, which uses the Secure Enclave.
That leaves the question of where the post-quantum component lives. Apple’s documentation on the Secure Enclave describes support for P-256 elliptic-curve keys, and explains that their security rests on there being no way to move them in or out of the chip (
Apple, Protecting keys with the Secure Enclave
). Hardware support for the P-256 component would not, on its own, imply that the ML-KEM component is also held in the chip. According to Apple’s documentation, however, CryptoKit also provides an ML-KEM-768 implementation that operates within the Secure Enclave, available since the 26 releases of Apple’s operating systems (
), and age-plugin-se uses it for post-quantum keys generated with the --pq option (
). Three conditions are therefore needed: a device with a Secure Enclave, an operating system that offers this feature, and a build of the plugin compiled with the relevant support; the plugin’s code explicitly handles the case where post-quantum is unavailable. I have not verified which device models are supported. Where the feature is available, the private component cannot be exported in the clear and is bound to the Secure Enclave.
Managing keys
Two situations need to be kept apart:
- device-bound keys, generated in the Secure Enclave: the private component cannot be exported in the clear;
- secrets an app chooses to store in the Keychain as synchronisable items may be copied to the other devices on the same account. iCloud Keychain is end-to-end encrypted (
Apple, iCloud data security overview
), but what a specific app synchronises depends on how it is built.
Hence the principle of compartmentalisation: one main key, carefully guarded, and keys dedicated to individual devices. The certain benefit is that no private key has to be shared between devices. Reducing the number of exposed documents, on the other hand, is not automatic: it depends on which recipients you include in each file. If every file is encrypted to every device, compromising just one of those keys is enough to open them all. In my view, for a key published as a professional channel, the most prudent choice is not to multiply its copies.
Keep in mind, too, that age has no revocation. Three scenarios need preparing, and they are different:
- planned rotation: generate a new pair, update the public key wherever it has been published, and keep the old private key to open earlier documents;
- compromise: replacing the published key protects future documents only if senders adopt the new key and stop using the old one; it does not protect those already encrypted with the compromised key, and you need to assess which ones are exposed;
- loss of the key or the device: without the private key, documents cannot be recovered. For exportable keys, the answer is a securely stored backup. For keys bound to the Secure Enclave, which cannot be copied, the answer is to add a backup recipient to the files you need to keep beforehand; if the hardware key is post-quantum, the backup recipient must be too.
Publishing a key verifiably
Publishing a key is not enough: whoever uses it must be able to trust that it really belongs to its claimed owner. Signing the file that contains the public key, or publishing it on several domains, proves control of those channels, not by itself the person’s identity.
One possible approach is to sign the age key file with a detached OpenPGP signature. The reader retrieves the signer’s OpenPGP key, verifies the signature and compares that OpenPGP key’s fingerprint with one obtained through another route. How much that comparison is worth depends on the channel the fingerprint came from. These are possible elements of verification, not automatic proof of identity:
- the fingerprint compared in person, if you recognise the person;
- the fingerprint printed on material you know comes from them;
- a channel that is already authenticated, as long as it is authenticated independently of the key being verified: otherwise the reasoning becomes circular;
for the OpenPGP key, if you trust the domain serving it: it distributes keys associated with an address, but does not by itself certify the person’s identity.
A caution about voice: recognising someone’s voice is no longer enough as proof of identity. In June 2025, Canadian authorities reported campaigns using AI-generated voice messages to impersonate senior officials and public figures (
). On the relationship between identity verification and artificial intelligence, see the dedicated section of my
.
A word on security.txt. Its purpose, according to
, is to make it easier to report vulnerabilities; the Encryption field points to a key to use in that context. It does not certify the owner’s identity, and the RFC itself leaves key validity out of scope.
Encrypted email or encrypted file
Encrypted email and encrypted files are not mutually exclusive. Encrypted email protects the message content; some metadata, such as sender, recipient and date, remain necessary for servers to deliver it, and attachments run into mail services’ size limits. An encrypted file travels over any channel and, stored as it is, keeps its encryption.
OpenPGP is also moving towards post-quantum.
extends the standard with post-quantum encryption and signature algorithms; GnuPG introduced Kyber/ML-KEM in its 2.5 series (
); Proton Mail offers post-quantum keys on all plans, to be enabled, for new encrypted emails (
). I have not verified the interoperability of post-quantum keys across these implementations: it should be tested before relying on it.
age in an AI workflow
In the
I argued that file encryption is not made obsolete by AI, but needs to be integrated into new workflows. age lends itself to this role by design: the project states its UNIX-style composability, and when no input or output file is given the program reads from standard input and writes to standard output (
). It can therefore be invoked by other programs, including an assistant coordinating a task. One possible integration workflow has five steps: I describe how it would work, without having verified any specific implementation.
- Receipt. The file arrives encrypted and stays that way. An agent can move and archive it, or catalogue it on the basis of the available metadata, without reading its content; with age-inspect it can read the recipient types declared in the header.
- Authorised decryption. This is the control point. Authorisation should cover that file and that operation, rather than being a general power granted to the agent. With keys held in the Secure Enclave, age-plugin-se can require Touch ID to decrypt (
): a confirmation that requires the user’s presence. The biometric confirmation, however, controls the use of the key, not the whole processing: on its own it does not show that the user has also approved the remote service, the purpose of the analysis or the sending of the result. The control point must make these choices visible too.
- Processing. It may happen on the device or in a remote service, ordinary or with isolation guarantees, as described in the main article. This is where you decide where the readable copy goes.
- Readable copies. The decrypted output can be passed straight to another program through standard output. This avoids explicitly writing an intermediate file, but you need to check how the next program handles the content, since it might keep it in logs, histories or files of its own. If a copy on disk is needed, decide where to save it and when to delete it.
- Encrypting the result. A summary or extract may retain confidential information, sometimes precisely the most sensitive parts, and calls for its own assessment and protection. Where needed, it can be encrypted again to already verified recipients, listed in a file maintained by whoever is accountable for it:
age -R verified-recipients.txt -o summary.md.age summary.md
If the recipients are post-quantum, the rule seen earlier applies: they cannot be mixed with classic recipients.
Throughout the workflow, the cryptographic operations remain with age; the assistant, if there is one, coordinates their execution. In my view, two checks should not be delegated: who the verified recipients are, and when decryption is authorised. In practice, the agent should only be able to use authorised tools, keys and destinations, and the content of a received document should not be able to change the list of recipients or authorise further sending.
age on iOS: a survey
On smartphones, as I noted in the main article, file encryption often remains easier on a computer. So I looked for iOS solutions, using explicit criteria.
- What I looked for: dedicated iOS apps with on-device processing; terminals that can install age; browser-based tools.
- Where: the
list curated by the age community
, the App Store via web search, GitHub.
- What I assessed: file encryption and decryption, X25519 keys, post-quantum keys, Secure Enclave, open source code.
- Limit: searching the App Store via the web is not exhaustive.
I found two dedicated iOS apps, both built by individual developers; only one claims support for post-quantum keys. Rather than recommending one, it is better to apply the criteria from the
: who develops the tool, whether published independent reviews exist, whether the published code matches the version you install, and whether the cryptography relies on established libraries. It is also worth remembering that a successful encryption and decryption test verifies interoperability for that version, not the app’s security.
There are also alternative routes, with limits:
- terminals:
can install age, but the documentation it ships dates from June 2024 and does not mention post-quantum keys; I have not verified the version.
uses Alpine repositories up to 3.19, and in 3.18 age is at
, without post-quantum support;
- browser tools:
and
accept post-quantum keys but only generate classic ones; the former handles text only.
handles files but not post-quantum keys. In every case the code that runs is the code provided by the site, and it can change from one visit to the next, so using these tools requires trusting the code served: during encryption it has access to the original document; during decryption it can also access the private key and the decrypted content;
- developer libraries:
, also by Filippo Valsorda, is the TypeScript implementation;
in Swift is a work in progress, and
has not been updated for some time.
The same criteria apply to these alternatives too.
Box: post-quantum, area by area
Verification date: 25 October 2026, within the survey carried out. Dates in the table indicate when a feature was announced or introduced; the status is what the sources consulted showed on the verification date, not the result of tests on the services. “Active” does not mean “everywhere”: the conditions column matters.
AreaToolStatusConditions and scope
WebHybrid TLSWidespreadOnly if both browser and server support it. Chrome has used hybrid key exchange with ML-KEM since version 131 (
); Apple enables it from iOS and macOS 26 (
). On the traffic Cloudflare observes, the share of human web traffic protected with post-quantum encryption grew from 29% at the start of 2025 to 52% in early December (
)
Remote accessOpenSSH 10DefaultHybrid key exchange by default since 10.0, if both sides support it (
)
MessagingSignalActivePost-quantum protection at session setup; continuous protection (Triple Ratchet) announced in October 2025 with a gradual rollout, between up-to-date clients (
)
MessagingiMessageActiveiMessage only, not SMS or RCS; from iOS 17.4 and macOS 14.4 (
)
MessagingSimpleXActiveDefault in direct chats since version 5.7 (
)
MessagingThreemaAnnouncedCollaboration with IBM Research announced in February 2026, no dates given (
)
EmailProton MailTo be enabledAll plans; once enabled, for new encrypted emails, while Proton plans to re-encrypt older ones in the future. The source does not make clear which exchanges with other providers are already covered: Proton says it is working with other projects, including Thunderbird, so that protection also works across providers (
)
EmailTutaActiveTutaCrypt protocol, active on all accounts since March 2026, for messages encrypted with recipients' Tuta keys; I have not verified messages to external addresses (
)
Files and emailGnuPG 2.5AvailableKyber/ML-KEM in the 2.5 series; interoperability with other implementations not verified (
)
FilesageAvailableSince 1.3.0; at the user's initiative, who must generate a post-quantum key; the sender must also use a version that supports it (
)
For WhatsApp, Matrix and Wire, I found no official announcements of post-quantum protection for conversations in production.
Box: a 7z archive with encrypted file names
For those who prefer a password-protected archive, the command below creates a 7z archive encrypted with AES-256 and, thanks to -mhe=on, also encrypts the list of files; the password is requested interactively (
;
).
7z a -p -mhe=on archive.7z document.pdf
The password must be strong and shared with the recipient over a different channel from the file.
Conclusion
age shows that file encryption can be simple, modern and already ready for post-quantum. The overall picture, however, confirms the main article’s thesis: automatic integration lowers the barriers to adoption. Where post-quantum protection is built into the browser, the operating system or the messaging app, it arrives without the user doing anything. Where it requires choosing a tool, generating keys and verifying them, it asks for extra effort. That effort is where the game is played, in AI workflows too: in my view, building age into those workflows as a component, with explicit checks on the steps that matter, is more realistic than asking everyone to use it by hand every time.
New to Gemini? This capsule is best read with a Gemini client, such as Lagrange.