Is it safe to use age for long term storage?

[jarjarfan666]

I see that age is still marked as beta in the releases page, but I'm wondering if it is stable enough for me to (symmetric) encrypt a file with it now, and come back to decrypt it after some years with a new version of age?

p.s: thanks for making such a user friendly encryption tool.

[samuel-lucas6]

It's unlikely that you'll be able to decrypt old files with a new version of age after several years because there are bound to be breaking changes at some point. However, you should still be able to download the old version you used and decrypt your files.

If you are concerned that age will disappear for some reason, you can just keep the age executable backed up.

Edit: See my later replies for better recommendations.

[Fastidious]

Today’s executable might not work at all 20-30 years from now. I still have files encrypted with PGP from 1993, which can be unencrypted without issues today. I assume that’s the OP concern.

[samuel-lucas6]

Today’s executable might not work at all 20-30 years from now. I still have files encrypted with PGP from 1993, which can be unencrypted without issues today. I assume that’s the OP concern.

You could say that about any executable. The best approach would be to consistently re-encrypt files with the latest version of age after there are breaking changes. I doubt the algorithms you used in 1993 are particularly secure today.

[alerque]

Saving binaries is not the way to make data safe! I realize that suggestion wasn't from the developer here, but any project that did say that would be a dead give away that they have no idea what issues plague archive projects or how to fix them.

If long term storage is an issue, the format being well documented and open is what will make or break the deal. In that sense the source code for the format being available is a much more meaningful data point than stashing a binary. However compiling ancient source code bases in the future is no picnic either, what's really important is that the format is well understood and implementable. If necessary and alternative implementation in some future language or system would be possible as long as the format isn't a secret.

Even something as ubiquitous as Word documents have been through this issue. Word itself can't read as old versions of it's own data as many open source implementations still can. Even though some old Word (and Word Perfect, Corel Docs, etc.) were closed formats they were reverse engineered and documented well enough that modern LibreOffice and other projects can handle them just fine. To make the situation better Microsoft eventually stopped using proprietary undocumented formats and switched to an XML based format that was at least easy to document (if still obtuse and cryptic).

The same is true for a lot of file formats from the 70-90s. Even things like zip files don't survive because you can run 80s era pkzip or it's 90s UI WinZip executables easily (although it can be done). They survive because the formats are understood and implementations keep up as long as they are useful.

The same will be true for age.

[samuel-lucas6]

Saving binaries is not the way to make data safe! I realize that suggestion wasn't from the developer here, but any project that did say that would be a dead give away that they have no idea what issues plague archive projects or how to fix them.

If long term storage is an issue, the format being well documented and open is what will make or break the deal. In that sense the source code for the format being available is a much more meaningful data point than stashing a binary. However compiling ancient source code bases in the future is no picnic either, what's really important is that the format is well understood and implementable. If necessary and alternative implementation in some future language or system would be possible as long as the format isn't a secret.

Even something as ubiquitous as Word documents have been through this issue. Word itself can't read as old versions of it's own data as many open source implementations still can. Even though some old Word (and Word Perfect, Corel Docs, etc.) were closed formats they were reverse engineered and documented well enough that modern LibreOffice and other projects can handle them just fine. To make the situation better Microsoft eventually stopped using proprietary undocumented formats and switched to an XML based format that was at least easy to document (if still obtuse and cryptic).

The same is true for a lot of file formats from the 70-90s. Even things like zip files don't survive because you can run 80s era pkzip or it's 90s UI WinZip executables easily (although it can be done). They survive because the formats are understood and implementations keep up as long as they are useful.

The same will be true for age.

You're right, I have no idea what issues plague archive projects. However, common sense tells me that it all depends on how long we are talking about. Keeping a backup of the source code, the version you used, and the binary seems like a better idea. However, if possible, re-encrypting files after breaking changes would be the most sensible option since that ensures that you're always using the latest version.

[Zegnat]

If long term storage is an issue, the format being well documented and open is what will make or break the deal. In that sense the source code for the format being available is a much more meaningful data point than stashing a binary.

To add to that, note that the age format is documented and mostly offloads the actual pieces to public RFC documents that have been found to be stable. This documentation has also meant at least one other implementation is able to exist. So hopefully this means support over time can be reached more easily than with undocumented or proprietary formats.

That said, AFAIK, long term storage is not an explicit goal of age. So it is up to the individual to make the call if they believe the current contributors will be around to keep it running, or if they believe they can keep the tool around for as long as they need without help. (I do not think GPG/PGP has long term storage as an explicit goal either? So you are making the same call there.)

[codesoap]

There is now a release candidate for v1.0.0: https://github.com/FiloSottile/age/releases/tag/v1.0.0-rc.1

[sergeevabc]

@jarjarfan666
In my opinion, Age’s UX leaves a lot to be desired, which makes using this app a torture. Notorious pitfall of PGP.
For example, you cannot simply encrypt a file by means of age -p "2021-03-14 Sunday musings on recent news.md"
and automatically get 2021-03-14 Sunday musings on recent news.md.enc or something like that. Instead you get
Error: refusing to output binary to the terminal. And even if you type the output filename manually, Age thus far
is too rigid to process command line switches in a common manner (e.g. learned from backup apps) of source-destination,
i.e. age -p "2021-03-14 Sunday musings on recent news.md" -o "2021-03-14 Sunday musings on recent news.md.enc"
returns Error: too many arguments. Not to mention you’re obliged to use another utility to generate keyfiles, whereas
it is expected to be built-in like Kryptor or Enchive does. All in all, it’s a modern algorithm with an outdated façade, that
reflects an utter incomprehension of what can be conveyed to a wide audience — think of a slide of some DefCon
presentation in the spirit of Moxie Marlinspike on why crypto is still a nightmare.

[FiloSottile]

I see that age is still marked as beta in the releases page, but I'm wondering if it is stable enough for me to (symmetric) encrypt a file with it now, and come back to decrypt it after some years with a new version of age?

This is a great question, and you're all right that this is not explicitly addressed in the documentation, which I should fix.

Long-term stability is a goal of age. As much as possible, we'll keep future versions of age able to decrypt files encrypted with any past version from v1.0.0 on. The only reason we'd break that promise is if decrypting an old file would expose the private key or other ciphertexts to a security risk, in which case we'd probably gate it behind an -insecure flag.

Technically we are not at v1.0.0, but it's very very unlikely the v1 file format will change at this point. In fact, I should probably give one last look at the Go API and tag v1.0.0.

For what it's worth, I have age ciphertexts (printed as QR codes) in safety deposit boxes that I don't plan to regularly access.

I'll keep this issue open to remember documenting this.