7 ms·

Paperback: An encrypted paper-based backup scheme

75 points by g0xA52A2A 5y ago

teaearlgraycold 5y ago
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.
- jagger27 5y ago
  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.
  - cyphar 5y ago
    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) https://en.m.wikipedia.org/wiki/ABC_(programming_language)
    - jagger27 5y ago
      > 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.
      - cyphar 5y ago
        > 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 https://github.com/cyphar/paperback/blob/main/DESIGN.md
    - Regular-Former 5y ago
      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 https://en.wikipedia.org/wiki/Pseudocode
      - cyphar 5y ago
- deleted 5y ago
  [deleted]
- dtonon 5y ago
  This was exactly the idea when I added the "self mode": https://github.com/dtonon/papiro https://github.com/dtonon/papiro :)
  - cyphar 5y ago
    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).
    - dtonon 5y ago
      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.
- cyphar 5y ago
  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]? [1]: https://en.m.wikipedia.org/wiki/ABC_(programming_language) https://en.m.wikipedia.org/wiki/ABC_(programming_language)
sigio 5y ago
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.
- cyphar 5y ago
  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 https://github.com/multiformats/multibase
  - cyphar 5y ago
    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 https://github.com/cyphar/paperback/actions
CiTyBear 5y ago
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
- artemonster 5y ago
  A decade ago it should‘ve been LISP :)
  - thecatster 5y ago
    We LISP people will never die, our time will come again :D
emptybottle 5y ago
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
armchairhacker 5y ago
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.
- CuriousCosmic 5y ago
  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).
  - killerpopiller 5y ago
    but doesn’t the printed text fade away before then?
    - cyphar 5y ago
      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.
- Brian_K_White 5y ago
  There is not. Not even close.
FearlessNebula 5y ago
Seems like a nice physical backup for a password manager export
rfd4sgmk8u 5y ago
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!
- cyphar 5y ago
  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.
newscracker 5y ago
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.
- cyphar 5y ago
  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.

75 points by g0xA52A2A 5y ago

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.

jagger27 5y ago
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.
- cyphar 5y ago
  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) https://en.m.wikipedia.org/wiki/ABC_(programming_language)
  - jagger27 5y ago
    > 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.
    - cyphar 5y ago
      > 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 https://github.com/cyphar/paperback/blob/main/DESIGN.md
  - Regular-Former 5y ago
    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 https://en.wikipedia.org/wiki/Pseudocode
    - cyphar 5y ago
deleted 5y ago
[deleted]
dtonon 5y ago
This was exactly the idea when I added the "self mode": https://github.com/dtonon/papiro https://github.com/dtonon/papiro :)
- cyphar 5y ago
  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).
  - dtonon 5y ago
    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.
cyphar 5y ago
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]? [1]: https://en.m.wikipedia.org/wiki/ABC_(programming_language) https://en.m.wikipedia.org/wiki/ABC_(programming_language)

sigio 5y ago

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.

cyphar 5y ago
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 https://github.com/multiformats/multibase
- cyphar 5y ago
  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 https://github.com/cyphar/paperback/actions

CiTyBear 5y ago

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

artemonster 5y ago
A decade ago it should‘ve been LISP :)
- thecatster 5y ago
  We LISP people will never die, our time will come again :D

emptybottle 5y ago

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

armchairhacker 5y ago

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.

CuriousCosmic 5y ago
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).
- killerpopiller 5y ago
  but doesn’t the printed text fade away before then?
  - cyphar 5y ago
    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.
Brian_K_White 5y ago
There is not. Not even close.

FearlessNebula 5y ago

Seems like a nice physical backup for a password manager export

rfd4sgmk8u 5y ago

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!

cyphar 5y ago
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.

newscracker 5y ago

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.

cyphar 5y ago
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.