Paperback: An encrypted paper-based backup scheme | Hacker News Reader

Paperback: An encrypted paper-based backup scheme

github.com

75 pointsg0xA52A2A28 comments

One use case it is you can share different number of key shard to individuals. Thus, they have more "power" based on how much you trust them.

If this is your will, you can give 3 shards to your sister (that you trust absolutely) and requires 4 shards to decrypt it. Your "semi-trusted" friends needs to be 4 to decrypt it, but your sister only needs to know one of your friend to access.

Written in rust for extra HN creds /s

A decade ago it should‘ve been LISP :)

We LISP people will never die, our time will come again :D

The problem is that QR codes are not information dense enough to encode large amounts of data efficiently. I have been trying to build something similar to this and using various encoding methods. So far, I have trouble getting more than about 64k on a printed page such that it can be optically recognized. The number of symbols in your encoding alphabet is important, and this reduces recognition.

I like this project and gives me some ideas on how to enhance my solution. Thank you!

The issue is that when I tested out various more dense solutions (DataMatrix, colour QR codes, or HCCB) I discovered that they are difficult to scan with most mobile scanners, meaning that while you can theoretically get fairly high data density on paper (no pun intended), you will struggle to actually reconstruct the original data.

But if you've figured out how to get even more density without making it difficult to practically read the data from the document I'd be very happy to hear about it and would gladly switch to that instead.

The image of an example document says something like “To recover the content, download the latest version of paperback from <URL>“.

I have a few questions about that.

1. Would that link even work after 10 or 20 or 30 years? What’s the fallback if the link is broken?

2. Is the “latest version” always guaranteed to be compatible with the scheme used by the document in question (again consider that the document is created now but is being attempted to be recovered a few decades from now)?

3. Based on the above questions, what’s a reasonable expected age for this system to work (I’m referring to the software)?

It would be useful to have these questions and their answers added in an FAQ on the site and in the repo.

This is a project I am still working on (I wasn't expecting it to be posted on HN), so while I have thought of the problems you've listed, I haven't finished solving all of them. I do appreciate the feedback though. To answer your questions:

1. My original plan was to have a textual description of the algorithm that you could print out and store with the key shards or main document. That way even if GitHub goes down and Rust is no longer available you could still pay someone to re-implement the algorithm to reconstruct the secret. That document could also contain a minimal version of the source code to just reconstruct the secret. The reason for putting a link to the website was so that a regular user (who is ultimately going to be the target audience for this) would be able to follow the instructions to recover the secret.

2. All of the data has a u32 version number inside the wire format, so any change which would render things incompatible would result in a new version and the code for recovering the old version would remain untouched (and once we get to that point, there would be tests to make sure that works). Also the document says in the header which paperback version was used to construct it, so even in the extreme case where we wouldn't be able to detect a change we could just ask the user what version of paperback does the document say.

3. Good question, but I'm not sure how I would go about estimating this?

I will add some of this information to the README.

Seems like a nice physical backup for a password manager export

Some documentation about how to go about decoding and inputting a document should be done.... I still haven't figured out how to do this after spending some time first trying to get it build (didn't build on debian stable, needed a debian testing chroot).

Now I can get the base64-strings from the qr-codes, but it's not clear how to pass this to paperback to decode the main document.

I'm still actively working on the project so I haven't documented things since they will likely change (to be easier to use) fairly soon.

At the moment you need to do the following (and the recovery procedure is a bit cumbersome -- there will be a GUI at some point for all of this since ultimately the project is intended for regular people):

% paperback backup [- or the file to back up] -n [threshold] -k [number of shards to make]

The command will print out the contents of the main document QR codes since at the moment the program can't scan the QR codes in the PDFs so you need to manually input the data. Note that the QR codes don't contain Base64 since that is not an efficient way of encoding binary data using QR codes. The QR code data is all encoded in Base10 (but the recovery code can handle any base data because I use multibase[1] prefixes).

And then to recover:

% paperback recover --interactive [- or the path to output the data to]

And it will ask you for the main document data (just copy-paste it, putting an extra newline after each segment) and then the shard data (you can copy-paste the "text fallback" segments from the QR codes) and shard codewords -- also with a newline after each section section. The prompts tell you what to input

"paperback expand" (create new shards from existing ones) works the same way (and also requires --interactive).

I plan to add support for just taking the PDF file and scanning the data from it directly but it seems a bit complicated to do at the moment, and I'm presenting a talk on this project next month at Linux.conf.au so I'm working on that talk right now.

[1]: https://github.com/multiformats/multibase

Also every commit has binaries built and uploaded via a GitHub Action[1] (though for some reason the x86 binaries aren't statically linked even though I'm using the musl toolchain).

[1]: https://github.com/cyphar/paperback/actions

Surely there's a better medium for long-term storage than paper? I can see this working for small documents, but if you have to print out thousands of pages you mine as well store the data on some kind of USB and maybe just print out the key shards.

It depends what's long term for you. If long term is 10-20 years then cold disk storage is probably acceptable provided you have some redundancy. However if for whatever reason you are aiming at 50, 100, or 100+ year storage, this is probably the safer approach (however like another comment mentioned, a decoding algorithm should probably be provided with the documents).

but doesn’t the printed text fade away before then?

Not with the right choice of paper and storage. In the bottom of the README I included a fairly detailed description of the basic precautions you can take to make the pages last as long as possible as well as links to several conservation groups and their recommendations.

The short version is you should use archival grade acid-free paper (acid breaks down ink and the page over time) and prefer encapsulation (storing inside an intert sleeve with the end taped or threaded closed) over hot lamination (the vinyl acetate in the laminate accelerates degredation).

We have managed to keep documents much older than 100 years in usable condition under far less ideal circumstances.

There is not. Not even close.

It's a thousand pages, give or take a few. I'll be writing more in a week or two. I could make it longer if you like the style. I can change it 'round, And I want to be a paperback writer, Paperback writer

It would be really cool if a small decoding binary could be printed on the back as a massive QR code. Then the paper would be all you'd need to recover the original document.

I feel like it would be easier to run a JavaScript program in 50 years than some binary format. Definitely a tricky question.

Something as important and as a will probably shouldn’t be encrypted in this fashion. Something more analog would be better.

I’m not sure if my descendants would appreciate having to compute Shamir and some key derivation function by hand just to read my will, but at least I could give complete instructions that aren’t bound to some vintage program that may or may not still be on GitHub in 75 years.

My original plan was to have a textual description of the algorithm since any choice of programming language or binary format might not be usable in 50-100 years time. Can you imagine if someone gave you a program written in ABC[1]? Another thing to deal with is what if QR codes are no longer used in 50 years time? Ideally we would just write it as text that can be read without a program so that it could be recovered even if all of the tools used to make it are long gone.

As for whether you should use this as a will -- I suspect you don't want to use this as your entire will (I'm not even sure if it would be legally enforceable in every jurisdiction -- the laws surrounding wills are quite complicated).

However, if you have some kind of digital asset that would be unsafe to include unencrypted in your will (cryptocurrency wallet keys are the obvious example but there are others) then this would be a supplement to your will. In addition, this program is also solving the issue that you want to have a backup of some sensitive data but not require you to have a long key that you will struggle to remember for decades.

[1]: https://en.m.wikipedia.org/wiki/ABC_(programming_language)

> My original plan was to have a textual description of the algorithm since any choice of programming language or binary format might not be usable in 50-100 years time.

I think any description of the algorithm at all would be better than the current "go to the website and download the latest version" situation. It should be enough to say which algorithms you use and the order. It looks like you've picked common enough ones that they shouldn't be lost to history.

> Another thing to deal with is what if QR codes are no longer used in 50 years time?

I'd imagine that many hundreds of years from now there will still be enough artifacts with QR codes on them that some historian will know what they are and how to decode them. They're far too common to be so easily forgotten, I think.

Maybe down the road instead of hiring a locksmith to crack your grandpa's safe, you'll hire a cryptosmith to crack into their paper wallet.

> I think any description of the algorithm at all would be better than the current "go to the website and download the latest version" situation. It should be enough to say which algorithms you use and the order. It looks like you've picked common enough ones that they shouldn't be lost to history.

I'm slightly more worried about encoding and the wire format of the various bits of data stored in the QR codes. You'd need slightly more detail than just the algorithms used. For the record, the entire design is actually outlined here[1] in lots of detail so really all that would be necessary would be encode that document as a PDF you can print and store with the backups.

[1]: https://github.com/cyphar/paperback/blob/main/DESIGN.md

Perhaps instead of any actual programming language you could use the pseudocode[1] used in scientific (comp-sci) papers. It should be understandable for longer than any current language.

[1]: https://en.wikipedia.org/wiki/Pseudocode

I suspect that would last longer, the issue is that it'd be harder for someone to practically use it because they'd need to pay a programmer to implement the algorithm for them -- while if we embedded a Python script (for instance) they would just need to ask a technically-literate person to show them how to run it. Though I suspect JavaScript would last the longest given how much internet culture has been written in JavaScript (and so long as projects like Archive.org exist, it should be possible to run JavaScript).

Ultimately doing both is probably better than one or the other.

This was exactly the idea when I added the "self mode": https://github.com/dtonon/papiro

Yeah, this is the simplest solution but it won't really stand the test of time either -- what if any one of the programs you have stop being developed or no longer can be compiled (zbarimg is the most obvious example -- I tried to get it working for Paperback but couldn't figure out how to make Java behave).

You can use any qrcode reader and simply concatenate the data streams. As usual if the specs are open source you are always able to recover the data, even without the original tools.

[1]: https://en.m.wikipedia.org/wiki/ABC_(programming_language)

Reply on news.ycombinator.com