I keep meaning to do something like this in combination with Shamir’s secret sharing (which allows you to split a secret into M blocks, of which any N can be combined to recover the key, and M and N are configurable) to distribute a private key among family members in case of my untimely demise so they can more easily access my financial accounts and stuff. Has anyone done that before, and if so, what tools do you prefer? My family members are nontechnical so that’s the biggest challenge.
mook · 1h ago
I've seen https://github.com/cyphar/paperback before which basically does this, I believe. I haven't used it in the context of letting other people recover things though.
Something similar, but encrypted, is PaperAge [1]. Admittedly, I haven't used it, but it seems like a nice solution for secure physical backup of small secrets. The catch, of course, is now you need to make sure you never forget your passphrase or back that up off-site somewhere else.
Something similar again is my little tool hemlis [0]
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).
The paper security backup "d'oh" equivalent to this would naturally be storing the encrypted PaperAge QR codes in the same physical location as the unencrypted QRkey paper containing the decryption key. Which would be hilarious to witness.
qualeed · 2h ago
What is the benefit of using a QR code over just printing and storing the document itself in a human-readable format?
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.
jeroenhd · 1h ago
The ability to store binary files comes to mind. PKCS12 certificate files and can't be turned human-readable without risking losing a flag or metadata or whatnot but the format is still widely used.
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.
dspillett · 1h ago
> What is the benefit of using a QR code over just printing and storing the document itself in a human-readable format?
Easier reading back. You don't want to be typing your private key in, and while scanning + OCR might be pretty reliable enough 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.
s0ss · 1h ago
Machine-readable expedited/convenient recovery as opposed to manual transcription.
Data entry sucks.
vorgol · 1h ago
> Data entry sucks
These are the kindest words I've heard about data entry.
kennyadam · 2h ago
Error correction?
techwolf12 · 2h ago
Personally, I use it for GPG private keys, and importing it again is easier with a barcode scanner than typing the entire file I've printed by hand.
musicnarcoman · 1h ago
As someone who made the mistake of printing keys only in human-readable format: ocr software is only so accurate.
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.
How safe is printing a private key, considering potential vulnerabilities in the printer software, firmware, and its online connectivity?
GTP · 14m ago
You're posing a good question but, if you look at things from this perspective, then every time you type the password to decrypt your private key you should worry about the possibility of some software running on your machine reading it and sending it somewhere.
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.
hypeatei · 1h ago
Tangential, but why is there a docker image for a simple command line tool like this? Surely a git clone is enough, especially for a Go app, no?
peckemys · 47m ago
Some people prefer to manage (or simply test) CLI tools, as simple or complicated they are, with Docker. You can setup an alias like 'alias qrkey=docker run --rm ghcr.io/techwolf12/qrkey:0.0.1' and run it as it was normally installed. In this example, as the image is created from scratch, the size would only be marginally bigger than the executable.
tantalor · 1h ago
> Recover from a PDF with QR codes with a barcode scanner
Barcode scanners scan bar codes, not QR codes.
detaro · 1h ago
QR codes are commonly considered a type of barcode. cf wikipedia: "A QR code, quick-response code, is a type of two-dimensional matrix barcode"
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.
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.
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.
https://github.com/kardianos/safekeysheet
[1]: https://github.com/matiaskorhonen/paper-age
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).
[0]: https://github.com/filleokus/hemlis
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 enough 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.
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.
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.
Barcode scanners scan bar codes, not QR codes.