[0]: https://github.com/matiaskorhonen/paper-age
Edit: I now see it was already mentioned.
Basically hand out transparencies to n people, and they all have to overlap to see the picture. It's like magic when you're playing with them.
It is a really fun idea and does not require deep technical knowledge to operate. The intent is for Bitcoin secret keys, but it can be used for any secrets.
While you pose a valid concern, I think most people don't have to worry about this. The reason is that printing private keys isn't a common practice, so I think it's unlikely that nation-states mandate backdoors in printer firmware to collect private keys, and most people don't have to worry about targeted attacks.
EDIT: On a second thought, your comment reminded me of that creepy time many years ago when a printer randomly regurgitated a partial print of a document I printed some time before (read: days or even weeks before), clearly showing that the printer kept it somewhere in memory. So it still possible that some printers memorize what you print. IIRC it was a Brother printer. At the end of the day, you can't account for every possible attack vector. Pick a reasonable threat model and act accordingly.
Yes, I believe you should. On OSes without sandboxing and protections against exfiltration, this is a substantial concern. And you’d be foolish to e.g. keep a bitcoin private key lying around in your home dir. For this same reason, I think the common practice of leaving non-password-protected SSH keys in ~/.ssh is terrible.
It uses Shamir's secret sharing algorithm to generate shares where the private key is split in n shares with k needed to reconstruct it. The bytes are encoded as word on a PDF (either 'burnt in' or written manually with pen to minimise the risk of storing them on printers etc).
That way you can spread the risk of loosing the physical key, while still maintaining some assurance that e.g your friends can run away with the key (or be compelled to hand it over to some threat actor).
You tag entries in your keepass DB with "safe-print", then point the tool to the db file, unlock it, then it generates a printout to put in your safe.
I'm trying to think of when/why I would want to add the extra step of converting to/from QR codes for the documents I keep in my safe, but I'm not coming up with any reasonable use case.
I'm sure I could just be missing the use case(s) the author has in mind, perhaps they should be suggested in the readme.
Edit: Several good examples below, thanks.
You could also use this as a basis for a printer+scanner system that exports and imports your system key store(s) automatically without having to risk OCR breaking your import.
Scanning a QR code is also just useful when it comes to entering long random strings. Although I agree that such a tool would do better outputting in plain text as well in case you need to enter it without a phone on hand, I think adding a QR code for loading the files quicker still makes sense.
Easier reading back. You don't want to be typing your private key in, and while scanning + OCR might be pretty reliable unless you are daft about font and text size choices getting text direct from the QR code on your phone (or direct into a PC/laptop if you have a scanner that perhaps types the content by pretending to be a USB keyboard), feels to me like it would be more convenient.
You can store a 2048-bit RSA private key in standard text form in a QR code, so after scanning to clipboard all you have to do is paste the text into an appropriate file, or again using the scan->HID option that is slightly more direct.
For longer keys you will need multiple QR codes, of course, and a very slightly more convoluted method. I have a couple of keys, SSH private keys and the master key for a keepass store (which is also on a USB token I carry), printed as QR codes stored in a secure place in this manner.
It looks like this tool does not allow for direct input from scanning the QR code(s) in the manner I've just described, as the description says it includes metadata for reassembly of larger data removing the simplest case for small data in favour of making larger data more convenient/robust.
Data entry sucks.
These are the kindest words I've heard about data entry.
I get your point, but a recovery/backup key? Yeah, I really rather have that human-readable, even if it means that I'll likely need a good 30 seconds to type that into wherever I have to type that in.
So if you have more than a handfull of bytes you may have to actually read it "by hand" to fix errors.
These days I keep the really important keys both as a qr codes and also hex. But the hex is not pleasant to work with.
http://github.com/alexjh/gpg-backup/
I printed to photo paper at the exact resolution my HP Photo printer needed, so the quality is excellent.
HOWEVER, backup keys are meant to be used in very rare cases. And in these very rare cases I'd like to have a backup key that I can directly type into a terminal with the keyboard. A QR key has one too many dependencies for my liking.
Barcode scanners scan bar codes, not QR codes.
