Hacker News Reader

Comment by edibleEnergy | Hacker News Reader

I was just (re-thinking) about this at work.. Just bought a Yubikey and was basically going to start from scratch with my PGP setup.

I really don't like the idea of storing anything really critical on a usb drive or an airgapped system.

I don't have an airgapped computer just laying around that I can store secrets on (and keep alive), and I don't trust a usb drive to last.

I really wish there was something like a clean way to store an encrypted printout that could be scanned years later if neccesary, ie a method of storage that I actually have faith would reliably survive for a decade or more.

View on HN

Could you store them as a series of QR codes, printed and laminated? Even if QR fades out of style, the algorithm is well-known.

Alternatively, if this is a "oh, shit" backup solution, you could just print and laminate the key, and enter it by hand years later, if necessary.

(This is just me thinking off the top of my head, mid-coffee. Ideas may be less valuable than they appear.)

https://github.com/4bitfocus/asc-key-to-qr-code looks like it is trying to do that, though the issues on the repo suggest it might not work 100%, which is kind of a deal-breaker.

The issues don't seem too problematic and looking at the code it's just wrapping qrencode. So it should be trivial to fix the three issues mentioned. I'd just halve the chunk size and post-process the generated QR codes manually in a image editing program to put multiple of them on the same piece of paper, including some textual information. Then laminate that.

I'll actually be doing this soon I think. Previously I used http://www.jabberwocky.com/software/paperkey/ which is quite good, but it's like two pieces of A4 filled with text which would be a huge pain to restore.

I was quite surprised how much text you can fit into a single QR code nowadays. 2778 bytes of lorem ipsum generates a massive code (1000x1000), but it can still be read passively with an iPhone's camera. For comparison, a Google CA cert is only 1363 bytes. You could theoretically dump your cert and private key onto their own (big) single page codes, then just scan them back in when you later need it. That just leaves the possibility of your printer holding onto something it shouldn't.

Use ECC keys or DSA+Elgamal keys. They are 100-150 bytes. That's just 5 lines of text when printed by paperkey. Much smaller than two full A4 pages!

Why does it need to be scanned years later? I suppose if you are mitigating the risk of going to prison or something like that, then it might make sense.

But either way, you can print to paper and store it in a fireproof safe (or probably better still -- a safety deposit box). There are lots of methods for ensuring printed paper survives for a long time -- if you google it, I'm sure you'll find more than you want to know.

My personal method is storing passphrase encrypted on multiple USB drives (they're cheap) and replacing them every year or so (they're cheap).

I think a more interesting question is: how do I provide access to my non-technical wife in case I am incapacitated or dead? Especially, how do I convince her not to put the passphrase on a sticky note on the fridge?

It'd be scanned years later if the USB drive I've backed it up on for regular infrequent use goes kaput on me ;)

The replacing every year or so sounds like the most robust way to do it with current best practices but that requires a lot of maintenance.

Encryption. If you encrypt files with the public key you are going to want to keep private key around long after the signature key is expired. The alternative is to decrypt and re-encrypt your files when you rotate keys out, but there is always a worry of forgetting something.

The best way to store data longterm on hardware is a QR code on a metal punch card, with holes for the black parts.

That would probably be the most robust method to withstand fire, rust and anything else.

You'd need access to a laser metal cutting machine for that though - or drill each hole one by one heh.

What about actual punch cards? Maybe not the most efficient given the lack of equipment but should not be harder to print or punch than QR. And standards were around for much longer than QR or DM so you can be sure to find some designs online or in a library if you lose all of of your equipment in 10-50 years (and they can always be scanned or read by eye if everything else fails). I'm looking for a simple design for a RS232 puncher, preferably one that would support some non-biodegradable plastic cards (they say PET bottles do not degrade in centuries, ain't that a perfect backup material?) But even paper cards should be more durable than anything printed on laser printer.

Using IBM 80-column cards you'd need just about 10 cards to store a 4096-bit key with three subkeys in binary mode. More if using char mode (might be preferred if you have to type them using keyboard). The key can be condensed for backup if needed. OTP and/or Shamir's method could be added to the mix to improve security, increasing the number of cards required, but even without Shamir you can split the deck in half and store in different places.

Longer, possibly foldable, punch tape is yet another option. If it has the same width as IBM 80-column cards then most of DYI equipment designed for the latter can still be used. It can't be metal though, only paper or plastic.

A bit of obscurity helps too, it's not like a deck of cards screams "this is an important secret" or possible attackers have card scanners with them when they invade your backup facility (although they can make photos and decipher them later so it's not real protection, just a small bonus.)

Now, how would we solve a problem of rubber-hose cryptoanalysis with it?

An air-gapped system is really just for key generation (or generating new subkeys). You really shouldn't store your key on the air-gapped system when you are done.

And you can just boot off a livecd while offline, that's a lot better than nothing :)

Wouldn't CDs do the job?

Common CD-Rs will only last a few years. Folks who rely on them for backup do well to rewrite their data to new discs on occasion.

Paperbak.

This is nice and all, but isn't practical for anybody on linux (Paperbak used to be windows only, and the linux version you can find is very subpar).

I have found that splitting the key in 256 bytes chunks, then QrCoding them is sufficient for my usage:

https://gist.github.com/Gui13/5e5fe0c7c67d55373767d4965b1638...

With that script, a 2048 bits key in PEM is about 4 pages (+ 5 others if I print it in text format), which I can store in a safe, and conveniently rescan using zbarcam anytime.

Reply on news.ycombinator.com