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.
yencabulator 13 hours ago [-]
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.
lozf 10 hours ago [-]
There's always paper-age[0] for those who want to add symmetric encryption (via age) to their qr-encoded secrets! ;)
I'll use my own printer, and after it dies on me, I will give it the Office Space treatment ;)
cornstalks 20 hours ago [-]
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 19 hours 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.
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.
EthanHeilman 16 hours ago [-]
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.
How safe is printing a private key, considering potential vulnerabilities in the printer software, firmware, and its online connectivity?
GTP 18 hours 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.
wrs 16 hours ago [-]
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.
GTP 12 hours ago [-]
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.
0cf8612b2e1e 16 hours ago [-]
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.
jcgl 4 hours ago [-]
> 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.
saclark11 20 hours ago [-]
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.
kardianos 18 hours ago [-]
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.
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 20 hours 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 20 hours 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 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 20 hours ago [-]
Machine-readable expedited/convenient recovery as opposed to manual transcription.
Data entry sucks.
vorgol 19 hours ago [-]
> Data entry sucks
These are the kindest words I've heard about data entry.
kennyadam 20 hours ago [-]
Error correction?
gukov 17 hours ago [-]
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
musicnarcoman 20 hours 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.
techwolf12 20 hours 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.
RamRodification 13 hours ago [-]
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?
lipowitz 13 hours ago [-]
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.
hypeatei 19 hours 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 19 hours 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.
I printed to photo paper at the exact resolution my HP Photo printer needed, so the quality is excellent.
thayne 15 hours ago [-]
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.
tantalor 19 hours ago [-]
> Recover from a PDF with QR codes with a barcode scanner
Barcode scanners scan bar codes, not QR codes.
detaro 19 hours 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"
thequux 17 hours ago [-]
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.
[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.
https://secretcodex32.com/
https://superbacked.com/
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.
[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
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
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.
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.
Barcode scanners scan bar codes, not QR codes.