I have some personal experience with this. I can't reveal much detail about my personal experience for opsec reasons.
Why maintain backups on paper?
Disks fail on the timescale of 5 years. Good quality paper and ink lasts atleast 30 years at minimum.
(If you use archival paper, archival ink and humid-free storage conditions, paper can last centuries. But also, it is hard to find printers that support this. Handwritten paper backups are a bad idea for uh ... reasons.)
Backing up the private key
There is atleast one project out there that backs up the PGP private key (encrypted by your passphrase) on paper.
But honestly, this is not hard. You can just print it the naive way, no additional software required. Make multiple copies so that you can restore backup even if one copy gets damaged. Mention the settings used to generate the key, and the pgp version number.
I think if you are going through the trouble of making paper backups, you should consider making a backup of the ciphertext too, for the same reason above, which is century-long durability.
Backing up the ciphertext
There is atleast one project out there that backs up the PGP ciphertext. Example
This is slightly harder because ciphertexts are big, and hence the resulting printouts are also big.
It is possible some of the paper gets damaged. One option is to implement a SOTA error correction algo, like Reed-Solomon. Another simpler option is to split the plaintext into chunks, encrypt each chunk separately, and make multiple copies of the ciphertexts.
Very important - You need to document exactly what method and software you used, otherwise you will not be able to restore the backup 30 years later. The software should still run 30 years later.
Very important - This is security software, so it is generally a bad idea to invent some ad-hoc solution, and a good idea to use some solution that is both verified by lots of experts and has seen lots of use in practice by other people. An ad-hoc solution would be, let's say, a shell script that converts everything to UTF-8 or ASCII plaintext, puts it in a tarball, splits it into chunks, encrypts each chunk.
Very important - You also need to stress test the whole restore process, including a script for that. Many backups are lost in the restore process.
For most media (images, audio, pdfs, etc), you probably want to lower the resolution and compress them, to avoid having to store boxes full of paper. For video files, you probably can't store them - you can store the audio sure, and store some frames of the visuals (maybe 0.1 FPS or 1 FPS).
Very important - You need to pick file formats such that the software that opens them will still run 30 years later.
Side Note
If you are using Tails (you probably should be), finding printers and scanners that work with Tails is non-trivial. Asking someone else to print it for you is a bad idea for obvious reasons.
Conclusion
I think software to backup PGP-encrypted ciphertexts is valuable to build, and not very difficult to build. The missing piece right now is cybersecurity experts willing to vouch for the security and usability of any particular software.
(Since ASI might be coming, working on projects like this is not highest priority for me. But I'm flagging this as useful, so that someone else might want to go work on this. Probably it will be someone who doesn't think ASI is coming.)
Subscribe
Enter email or phone number to subscribe. You will receive atmost one update per month