When I worked at a company called Smarsh, I wrote an encrypted file format for them for use in cloud agnostic storage utilizing envelope encryption. I read dozens of state of the art documents, various RFCs, and researched even proprietary formats for prior art references.

We also used Go, which I consider the best possible language to use with respect to working on encryption. Kudos to Filippo Valsorda for his work on Go, and age. Hands down the best work in the space at the moment. It doesn't get better. I've done my homework.

But in my opinion, this is still an unsolved problem. age simply makes a dent in an otherwise immature space, with simple questions:

1. What cyphertext, salt, iv structure layout should the encrypted payload follow? There are de facto binary structure layouts that prior art has established a practice for, but it does vary in order, and no papers talk about embedding specific details you need for the decryption process such as required lengths that otherwise need agreed upon static values.

2. What headers should be provided, if any, to provide mechanisms for versioning and reading encryption strategy? Should part of this metadata be in the file extension instead, such as `.aes256-gcm' and `.aes256-gcm.key'?

To my surprise, despite the longevity of the industry, there was no simple file format that I could turn to that didn't involve being tightly coupled to email or a concept of a recipient.

Unfortunately, age was:

1. Too young to consider for enterprise rollout.

2. Failed to differentiate itself from previous standards that were tightly coupled to email or recipients.

3. It fails to meet encryption standards that are more aligned with compliance than the state of the art.

Regarding point 3, I appreciate its desire to stay small and utilize ChaCha20-Poly1305, but that's insufficient for deployments with specific requirements.

I think someone needs to come out with an alternative to age that allows you to specify the cipher, and supported ciphers in the standard need to have specific binary layouts that can be agreed upon.

I would personally prefer some metadata in the file extension, but I think this is naive, because re-encrypting a file would lose this information, or dumping binaries to pathnames with arbitrary file names would destroy this information, so it must be in a file header.

The file header needs a specific magic number that can be read by utilities, and those utilities can further probe the file for metadata.

age does some of these things, but it doesn't have answers for others.

But gpg isn't a solution, either. Nor are numerous other encrypted payload formats for various reasons.