Is it safe to use age for long term storage? #215
-
|
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. |
Beta Was this translation helpful? Give feedback.
Replies: 9 comments 5 replies
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 The same will be true for age. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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.) |
Beta Was this translation helpful? Give feedback.
-
|
There is now a release candidate for v1.0.0: https://github.com/FiloSottile/age/releases/tag/v1.0.0-rc.1 |
Beta Was this translation helpful? Give feedback.
This comment was marked as disruptive content.
This comment was marked as disruptive content.
-
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 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. |
Beta Was this translation helpful? Give feedback.
-
|
Opened #216 to track adding a backwards compatibility policy. |
Beta Was this translation helpful? Give feedback.
-
Looking at doing something like that myself. Would be nice to have a BIP-39 like scheme to import/export the private key in a more human-friendly way — I don’t know what the story will be for decoding QR codes in, say, 20 years from now. |
Beta Was this translation helpful? Give feedback.
-
|
One can use BIP-39 as-is to turn an age identity into a 24 words mnemonic. I wonder if we should teach age-keygen that or make a separate tool. |
Beta Was this translation helpful? Give feedback.
-
|
Opened #277 |
Beta Was this translation helpful? Give feedback.
-
|
Well, in the spirit of "we don’t know what will happen in the next 20 years", backing it in age-keygen rather than a separate tool seems a safer bet. |
Beta Was this translation helpful? Give feedback.
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…