5 ms·

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

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
    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.

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
  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.