Be careful where you print these. Most full-featured printer/copier/scanner devices found in office environments can store print job data on the HD where service technicians can access it.
For extra fun, the printer is likely either on the network or has bluetooth. Age-old poorly written embedded computer with network services written in C is the industry standard. It's totally plausible to break in and steal previously-printed data.
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.
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.
Codex32 allows you perform Shamir secret sharing operations and error correcting code without using a computer. Instead, you can perform the operations by hand using cardboard code wheels called volvelles.
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.
One use that I've seen reported whas when Naomi Wu / SexyCyborg was taken into custody by Chinese gov't officials, her friends used SSS to gain access to her social media accounts to report the abduction.
We use shamir to be able to activate a special internal service.
We at least need to person to activate it.
Also Hashicorp Vault (and forks) are using it to seal/unseal the cluster.
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.
This certainly applies to office printers. Printers that accept new jobs while printing have to store them somewhere. There have been many incidents of finding old documents on disposed printers because it doesn’t occur to anyone to wipe them first. This especially applies to “copiers”, because a copier is just a printer in the same box as a scanner.
But that wasn't an office printer. Yes, printers do have some memory to store what they need to print, but surely I didn't expect a document to linger there for weeks. Anyway, you're right: we may have to look at printers differently.
There was a conspiracy theory that China was buying old office printers/scanners hoping to recover secret documents remaining in the cache. Plausible, but seems like a lot of effort hoping for a diamond in the rough when I expect 99% of prints are boring day-to-day information.
> 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.
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.
Sure it's a bad idea to not encrypt your private keys, but the point here was that, even if you encrypt them, they will be unencrypted when you need to use them.
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.
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.
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.
> 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 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.
How often do you have to recover a key? I think I did it maybe 3 times in the past 5 years.
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.
Yep, if I'm using a physical medium like paper I want to allow for some degradation. Here's a Veritasium video on QR codes: https://youtu.be/w5ebcowAJD8
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.
The usage guide shows which command to run to generate a QR code from a file, and outputs a PDF. But then the command for recovering a file from QR codes takes "file.txt" as input. Is that a typo? Shouldn't that input also be a PDF?
This is a neat idea, but unfortunately not very useful to me. I don't own a printer, and I don't want to trust my private keys to a public computer and printer.
I know that QR keys are designed in a way that protects from visual degradation.
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.
Many barcode scanners these days can scan QR codes. I have a NetumScan NSL5 that I got for €30 or so that can handle QR, DataMatrix, and even Aztec codes.
Be careful where you print these. Most full-featured printer/copier/scanner devices found in office environments can store print job data on the HD where service technicians can access it.
There's always paper-age[0] for those who want to add symmetric encryption (via age) to their qr-encoded secrets! ;)
[0]: https://github.com/matiaskorhonen/paper-age
Edit: I now see it was already mentioned.
For extra fun, the printer is likely either on the network or has bluetooth. Age-old poorly written embedded computer with network services written in C is the industry standard. It's totally plausible to break in and steal previously-printed data.
I'll use my own printer, and after it dies on me, I will give it the Office Space treatment ;)
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.
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.
Visual cryptography is really cool. Shamir and Naor came up with an algorithm in the 90s: https://en.wikipedia.org/wiki/Visual_cryptography#Example
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.
Codex32 allows you perform Shamir secret sharing operations and error correcting code without using a computer. Instead, you can perform the operations by hand using cardboard code wheels called volvelles.
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.
https://secretcodex32.com/
One use that I've seen reported whas when Naomi Wu / SexyCyborg was taken into custody by Chinese gov't officials, her friends used SSS to gain access to her social media accounts to report the abduction.
We use shamir to be able to activate a special internal service. We at least need to person to activate it. Also Hashicorp Vault (and forks) are using it to seal/unseal the cluster.
superbacked, now free and open source, does exactly this.
https://superbacked.com/
There was also a good thread about paper storage the other day: https://news.ycombinator.com/item?id=44142565
How safe is printing a private key, considering potential vulnerabilities in the printer software, firmware, and its online connectivity?
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.
This certainly applies to office printers. Printers that accept new jobs while printing have to store them somewhere. There have been many incidents of finding old documents on disposed printers because it doesn’t occur to anyone to wipe them first. This especially applies to “copiers”, because a copier is just a printer in the same box as a scanner.
But that wasn't an office printer. Yes, printers do have some memory to store what they need to print, but surely I didn't expect a document to linger there for weeks. Anyway, you're right: we may have to look at printers differently.
There was a conspiracy theory that China was buying old office printers/scanners hoping to recover secret documents remaining in the cache. Plausible, but seems like a lot of effort hoping for a diamond in the rough when I expect 99% of prints are boring day-to-day information.
> 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.
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.
Sure it's a bad idea to not encrypt your private keys, but the point here was that, even if you encrypt them, they will be unencrypted when you need to use them.
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.
[1]: https://github.com/matiaskorhonen/paper-age
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).
[0]: https://github.com/filleokus/hemlis
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.
Nice, I'll add to the list of similar thing I made, specifically for keepass.
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
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.
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.
> 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 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.
Machine-readable expedited/convenient recovery as opposed to manual transcription.
Data entry sucks.
> Data entry sucks
These are the kindest words I've heard about data entry.
How often do you have to recover a key? I think I did it maybe 3 times in the past 5 years.
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.
Error correction?
Yep, if I'm using a physical medium like paper I want to allow for some degradation. Here's a Veritasium video on QR codes: https://youtu.be/w5ebcowAJD8
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.
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.
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?
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.
The usage guide shows which command to run to generate a QR code from a file, and outputs a PDF. But then the command for recovering a file from QR codes takes "file.txt" as input. Is that a typo? Shouldn't that input also be a PDF?
It isn't the PDF you started with once you print it.. A QR code scanner in a camera app, etc, will return text such as a URI.
Ah, makes sense. Thanks.
I set up a similar system:
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.
This is a neat idea, but unfortunately not very useful to me. I don't own a printer, and I don't want to trust my private keys to a public computer and printer.
I know that QR keys are designed in a way that protects from visual degradation.
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.
> Recover from a PDF with QR codes with a barcode scanner
Barcode scanners scan bar codes, not QR codes.
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"
Many barcode scanners these days can scan QR codes. I have a NetumScan NSL5 that I got for €30 or so that can handle QR, DataMatrix, and even Aztec codes.