The CNC router's firmware? The CNC controller itself is dumb as hell. It's connected via serial to an old offline computer that's only job is to pipe G-code over RS-232. Not even to "load a program" to hold in memory on the controller. Literally to stream the commands to the machine.
If the CNC machine is not connected to a network, and (I don't know much about CNC, but I do wonder) if one can provide a generic program, then just fill in the parameters before execution, right at the machine, the secret would be confined to just the CNC machine.
Regardless, provided the CNC machine is not networked, and provided it doesn't have any solid state (only RAM), one could perhaps load a large job to overrite the previous one.
Although, perhaps the CNC machine could be used to just provide templates, with small indentations for where the holes could be punched, and additional engraving to provide a link to a document on how to use the card in case of disaster recovery.
Sometimes CNC machines are networked, sometimes not, but the idea behind saving keys like this is that you only generate the appropriate bits on disposable computers, e.g. a Raspberry Pi with an SD card you can then destroy.
It depends on how much money you want to secure, of course, so YMMV.
Nice! With a denser 256 bit card you could store an entire age secret key, and so encrypt any amount of data directly to metal key asymmetrically, only needing the public key at encryption time (keeps metal key safer).
Then thresholding can be done with "sops" (which uses the Hashicorp vault shamir implementation) against groups of age keys. Making it so M of N metal backups are required to decrypt the nuclear codes you're storing.
Indeed, this is another use case I've had in mind. (Protect a X25519 private key, and use the public key to encrypt against, without the need to have the private one online.)
However, the current scheme supports only 128 bits, thus requiring two cards per X25519 secret key. (One could of course, extend the sheet to another four blocks.)
Alternatively, one could do either one of the following:
* with the help of `age` (which uses X25519 keys), create a private / public key pair, and use a random secret as the private key password;
* given how X25519 secret keys work (i.e. almost any 256 bit random number, after some tweaking would do), one can just create a random 128 bit number, backup like described here, then to get to a X25519 key, use something like `HMAC-SHA256(key="00bbcc...", message="description of key")` to get the cryptographic material for the X25519 key; (thus one could have an infinite supply of X25519 keys, starting from just a simple 128 bit secret;)
(This second scheme, might reduce the strength of the resulting X25519 keys, however I doubt they can be broken, given the requirement to brute-force the HMAC-SHA256.)
I like the survivability, and the constraint to be doable with common hand tools.
For more information density, and easier readability by a less-technical person who inherits it -- at the cost of requiring special tools -- I wonder about using number&letter stamps with a hammer.
Or, if you permit very special tools, laser-cut alphanumerics (base16, base58, or base64, for arbitrary bits; or alphabetic passphrases). Either engraved, or cut fully through, like an old drafting lettering stencil.
This is a problem the cryptocurrency community has been dealing with for almost a decade: how to securely store a seed phrase backup (48 characters, the first 4 characters of 12 words).
Letter stamps are one option. A number/letter grid you use a simple punch with are much more dense than this but still easy to do with hand tools. There are lots of products with pre-made stamped letter tiles that slide into slots.
Reminds me of the physical keys we’d in the army. Though they were designed to not be long lasting, I think they were paper strips that could be burned after using mission impossible style.
It needs a new kind of punch that can't easily be photographed and it needs to be waterproof. Magnets seem good. Could make them disc shaped.... wait...
Make sure it's stored in an electrochemically inoffensive environment, including considerations like dissimilar-metal contact, etc. Aluminium is a good choice here especially for being both easily worked and self-passivating in air, but it has some more obscure vulnerabilities which can have impact over decades.
This is how much I could pack on a standard (CR80 ID) card sized plate, while still being able to punch the holes without power (or precision) tools. (The aspect of ease of creation with household items was paramount for my design.)
There is also the problem of long term durability. Not being a construction engineer, or metallurgist, I have no idea what is considered "survivable" in case of an unlikely accident (such as fire, flood, crash, etc.), especially if one uses aluminium as the material. The more holes, the smaller the holes, I think the less likely chance they wouldn't degrade easily if not treated with care. (Aluminium is cheap, easy to work with just a cutter, screwdriver, and ruler.)
Moreover, 128 bits is plenty enough for encryption purposes. The AES standard uses key sizes of 128, 192 and 256 bits, but at the moment even the 128 bit keys provide plenty enough security.
Thus, if one needs to store more than 128 bits, one could just use a standard encryption tool like Age or GnuPG, and backup just the password. (The encrypted file could be mirrored all over the place without fear of brute-forcing.)
I had to look it up, an IBM card format 80x12 is 187x83 mm. Roughly 0.06 bits/mm^2. The CR80 is 86x54mm for the 128bits, 0.03 bits/mm^2. Not a terrible difference for accommodating hand tools.
Edit: If my first search results are to be believed, the first magnetic hard drive had a density of 3.1 bits/mm^2
Plus just place punch card on paper apply a paint with brush of better spray and you printed your holes will be printed on paper share anyone (Softcopy ツ)
alternatively for fun use photographic chemical film paper and dark room, place plate on light source flash and capture holes on film
Steganography ideas
Another fun-> divide cut plate into puzzle give pieces to different people only when puzzle combined reveals full datà
Another -> Have two or more plates with extraa binary bits holes and masking plates, when they are superimposed/stacked in proper order or aligment then uncessary bits will be masked revealing useful bits
With regard to the puzzle idea: if the secret is quite sensitive, and assuming you split the card in say 4 parts, then coercing 2 of them to reveal their puzzle pieces, would reduce the brute force security of the secret from 128 bits to just 64 bits, which could be easily breakable.
With regard to the superimposed cards idea: this is equivalent with an "and" operation on bits, which in terms of entropy means that having one of the cards would reduce the brute force security by the amount of "0" bits (i.e. non holes in the card), because those bits can never be "1" due to superimposing.
The only safe way one can *easily* create multiple shares is through bit-wise XOR-ing:
* generate two random number, encode them into the cards, the actual secret is the XOR of the two numbers;
* K out of N is possible (I've seen some articles / StackOverflow posts), similar (though not quite exactly) to how RAID5 handles data;
The only one minor issue with this snippet (which I now just realized), is that if the secret has the first few bits on zero (i.e. anything that starts with something under `7`) then the resulting bits would be less than 128, and thus the user has to copy them from right to left (the least significant one) on the card from bottom-right upward.
Alternatively, one could use the `.rjust(128,"0")` to pad the bits, as in:
Like this product, there are many other products that focus on allowing one to back-up crypto-currency wallet seed phrases.
However, they all have in common the following major disadvantages:
* cost -- I can't see myself paying 50+/100+/150+ EUR for such a product, no matter how fancy is the marketing;
* they are meant primarily to encode ASCII passphrases, thus they have low information density; (most formats allow one to encode only one letter per column;)
* size / format -- I want something easily portable, not a large slab of metal, or a heavy paper-weight; (thus I've used the standard CR80 ID card size;)
Provided that the information one wants to keep safe is sensitive and important long term, there are two main issues with printing (either text, QRCode, or anything):
* (paranoia) can you trust your printer not to leak the secret? (either in local memory, or to send it to its cloud mother-ship?) you can encrypt your information and print that, but then you are back to square one: where do you backup the password;
* and most importantly, long term resilience: given that with normal printers you can only print on soft materials (like paper, or perhaps plastic), they won't last floods, fire, and other unlikely events; (even if one laser etches some information on a steel sheet, I don't know how resistant to abrasions it is;)
However, by actually drilling holes into a metal sheet, the only way to permanently make the data irrecoverable, is to destroy the object completely.
For point 1 I recall the creator of Age, Filippo Valsorda suggesting something similar:
>The .age-recipients files also include the public key for an offline disaster recovery key. I generated the key with age-keygen, encrypted it with age -p, printed the ciphertext as a QR code, and wrote the random passphrase in pen. This is a bit convoluted, but I don’t trust printers. All this was done in a tmpfs, so nothing reached storage. Only had to do this once, and have been using that key as the anchor for all my disaster recovery data.
https://words.filippo.io/dispatches/passage/
> Cool but wouldn’t you forget how to decode it after some time?
Not necessarily.
First of all there isn't much decoding to be done: if one follows the recommendation, and one uses the hex input variant as the password (or secret), then decoding is as simple as just writing the number is binary base. For example this password `d74ae47dc6f599d3f9cb847bd77d6b7c` can be recovered by simply starting a Python interpreter and writing `"%032x" % b1101011101001010...`
Moreover, by just providing the card to a computer science graduate / enthusiast, his first hunch would be to just try to convert the bits into a number and use that (either base10 or base16), perhaps after rotating / flipping the card (if he didn't knew about the alignment). (This can easily be deduced because there are 2 groups of 8x8 bits.)
(Alternatively, if one scratches on the card the URL `purl.org/999/1`, provided Archive.org, which currently hosts PURL.org, doesn't delete the links like Google just did with `goo.gl`. I intend to update the redirect from this PURL to a page hosted by Archive.org.)
> I.e. wouldn’t engraving regular characters be simpler?
The first, and perhaps greatest issue, is that not many people have access to engraving hardware. One could go to a shop and have the characters engraved, but then they wouldn't be secret.
So, the main purpose is this: how could one with minimal access to power or precision tools, create the sturdiest physical backup of a small piece of information.
Thus this proposal: with a sheet of metal, a nail, and a hammer, one could just encode the 128 bits by banging with the hammer on the nail through the sheet of metal. :)
Perhaps one could engrave without specialized hardware, i.e. increase the nail and hammer dpi resolution a bit, use a pixel font and become a human dot matrix printer.
But yes, punch card decoding may be not a problem and a punch card could be fine too - and definitely much cooler.
You could laser etch redundant instructions on the back of the card. Sure, a few particular pieces of information might be punched out, but should be enough guide posts to reconstruct the encoding.
Besides the issue with printing and paper longevity, another issue with QRCodes is that you can't easily convert them back to data without a proper application that implements the decoding algorithm, and thus you need to extend your trust to the application you use to recover the data.
However, with the proposed format (which is in fact just the oldest storage technique in computer history), one can just use a pen and paper (or any dumb 70s calculator) to easily convert the backup into something usable.
For example: group 4 bits together, and compute `b1*8 + b2*4 + b3*2 + b4` to get the index of a hexdigit; write that down choosing between `0-9a-f`; move to the next group; and that's your password.
I can think of a couple of advantages. For one, punching these holes takes time (and physical space on the object), and a high-redundancy QR code’s extra holes don’t gain you much: instead, this approach situates the redundancy in the physical properties of the object itself.
For two, did you see the encoder/decoder script? Barely two lines of python! Which truly are optional, I guarantee many people here could encode and decode that pattern by eyeball. I know one can hand-calculate a QR code, but why would I when I can use raw bits?
Initially the bits were counted from 0, however this had two issues:
* using 0 as starting point would immediately trigger one's "computer science" instinct, and then it's uncertain which bit is actually bit `0`? the least significant one (as is in most cases), or the most significant one?
* by using 1 as the starting point, I hope would induce most people to just use it as a counter to number things in the "normal" (for westerners) left-to-right top-to-bottom, thus encoding / decoding is more "natural";
Absolutely makes sense. I have a 1960s desk tchotchke paper tape punch and I am tempted to cut my password store keyphrase into a tape in 7 bit ASCII with checksum as a super-encoded string, and then put it in the tombstone letter with the USB stick and instructions for decoding running the home filestore. A friend has a 3D printer and I think a small optical (light behind) reader and a decode table print might do the trick. There is the sprocket holes in paper tape but the weakness is driving things, and the tape roll is now 5 decades old, so the risk of a tear is there.
I'd do it in my stash of hollerith cards, but I don't have a desk punch. I suppose I could simply take some of the pre-punched ones, and use them as the key phrase!
I love this so much. This, this right here is why I still visit Hacker News.
I'm going to use this today and pave a path to my CNC router to make it stupidly easy to generate these plates on-demand.
Thus defeating the entire purpose! Unless you plan to wipe your router's firmware after every one.
The CNC router's firmware? The CNC controller itself is dumb as hell. It's connected via serial to an old offline computer that's only job is to pipe G-code over RS-232. Not even to "load a program" to hold in memory on the controller. Literally to stream the commands to the machine.
My CNC controller has an SD card, Wifi, Bluetooth, and USB. They're not all the same.
Fancy!
If the CNC machine is not connected to a network, and (I don't know much about CNC, but I do wonder) if one can provide a generic program, then just fill in the parameters before execution, right at the machine, the secret would be confined to just the CNC machine.
Regardless, provided the CNC machine is not networked, and provided it doesn't have any solid state (only RAM), one could perhaps load a large job to overrite the previous one.
Although, perhaps the CNC machine could be used to just provide templates, with small indentations for where the holes could be punched, and additional engraving to provide a link to a document on how to use the card in case of disaster recovery.
Sometimes CNC machines are networked, sometimes not, but the idea behind saving keys like this is that you only generate the appropriate bits on disposable computers, e.g. a Raspberry Pi with an SD card you can then destroy.
It depends on how much money you want to secure, of course, so YMMV.
Nice! With a denser 256 bit card you could store an entire age secret key, and so encrypt any amount of data directly to metal key asymmetrically, only needing the public key at encryption time (keeps metal key safer).
Then thresholding can be done with "sops" (which uses the Hashicorp vault shamir implementation) against groups of age keys. Making it so M of N metal backups are required to decrypt the nuclear codes you're storing.
Indeed, this is another use case I've had in mind. (Protect a X25519 private key, and use the public key to encrypt against, without the need to have the private one online.)
However, the current scheme supports only 128 bits, thus requiring two cards per X25519 secret key. (One could of course, extend the sheet to another four blocks.)
Alternatively, one could do either one of the following:
* with the help of `age` (which uses X25519 keys), create a private / public key pair, and use a random secret as the private key password;
* given how X25519 secret keys work (i.e. almost any 256 bit random number, after some tweaking would do), one can just create a random 128 bit number, backup like described here, then to get to a X25519 key, use something like `HMAC-SHA256(key="00bbcc...", message="description of key")` to get the cryptographic material for the X25519 key; (thus one could have an infinite supply of X25519 keys, starting from just a simple 128 bit secret;)
(This second scheme, might reduce the strength of the resulting X25519 keys, however I doubt they can be broken, given the requirement to brute-force the HMAC-SHA256.)
I like the survivability, and the constraint to be doable with common hand tools.
For more information density, and easier readability by a less-technical person who inherits it -- at the cost of requiring special tools -- I wonder about using number&letter stamps with a hammer.
Or, if you permit very special tools, laser-cut alphanumerics (base16, base58, or base64, for arbitrary bits; or alphabetic passphrases). Either engraved, or cut fully through, like an old drafting lettering stencil.
This is a problem the cryptocurrency community has been dealing with for almost a decade: how to securely store a seed phrase backup (48 characters, the first 4 characters of 12 words).
Letter stamps are one option. A number/letter grid you use a simple punch with are much more dense than this but still easy to do with hand tools. There are lots of products with pre-made stamped letter tiles that slide into slots.
Agree, going from binary to a higher base, e.g null, hole, + and -, would increase information density drastically (in 256 times in this case).
Reminds me of the physical keys we’d in the army. Though they were designed to not be long lasting, I think they were paper strips that could be burned after using mission impossible style.
You might also enjoy paperback:
https://github.com/cyphar/paperback
https://www.youtube.com/watch?v=GI9rKdM9rB8&list=PLD8dAKx4J2...
Wouldn't printing a QR code be way easier? If it's just for retro fun / Rube Goldberginess than nevermind, carry on :)
It needs a new kind of punch that can't easily be photographed and it needs to be waterproof. Magnets seem good. Could make them disc shaped.... wait...
Please see my reply to this other similar question:
> Looks like a new 2d barcode format to me. Why I would want this rather QR or any other that have redundancy built in?
https://news.ycombinator.com/item?id=44145202#44145279
This will survive a house fire.
Make sure it's stored in an electrochemically inoffensive environment, including considerations like dissimilar-metal contact, etc. Aluminium is a good choice here especially for being both easily worked and self-passivating in air, but it has some more obscure vulnerabilities which can have impact over decades.
Just 128 bits? I expect punch cards to hold 80 columns of 12 bits :-)
This is how much I could pack on a standard (CR80 ID) card sized plate, while still being able to punch the holes without power (or precision) tools. (The aspect of ease of creation with household items was paramount for my design.)
There is also the problem of long term durability. Not being a construction engineer, or metallurgist, I have no idea what is considered "survivable" in case of an unlikely accident (such as fire, flood, crash, etc.), especially if one uses aluminium as the material. The more holes, the smaller the holes, I think the less likely chance they wouldn't degrade easily if not treated with care. (Aluminium is cheap, easy to work with just a cutter, screwdriver, and ruler.)
Moreover, 128 bits is plenty enough for encryption purposes. The AES standard uses key sizes of 128, 192 and 256 bits, but at the moment even the 128 bit keys provide plenty enough security.
Thus, if one needs to store more than 128 bits, one could just use a standard encryption tool like Age or GnuPG, and backup just the password. (The encrypted file could be mirrored all over the place without fear of brute-forcing.)
I had to look it up, an IBM card format 80x12 is 187x83 mm. Roughly 0.06 bits/mm^2. The CR80 is 86x54mm for the 128bits, 0.03 bits/mm^2. Not a terrible difference for accommodating hand tools.
Edit: If my first search results are to be believed, the first magnetic hard drive had a density of 3.1 bits/mm^2
Plus just place punch card on paper apply a paint with brush of better spray and you printed your holes will be printed on paper share anyone (Softcopy ツ)
alternatively for fun use photographic chemical film paper and dark room, place plate on light source flash and capture holes on film
Steganography ideas Another fun-> divide cut plate into puzzle give pieces to different people only when puzzle combined reveals full datà
Another -> Have two or more plates with extraa binary bits holes and masking plates, when they are superimposed/stacked in proper order or aligment then uncessary bits will be masked revealing useful bits
With regard to the puzzle idea: if the secret is quite sensitive, and assuming you split the card in say 4 parts, then coercing 2 of them to reveal their puzzle pieces, would reduce the brute force security of the secret from 128 bits to just 64 bits, which could be easily breakable.
With regard to the superimposed cards idea: this is equivalent with an "and" operation on bits, which in terms of entropy means that having one of the cards would reduce the brute force security by the amount of "0" bits (i.e. non holes in the card), because those bits can never be "1" due to superimposing.
The only safe way one can *easily* create multiple shares is through bit-wise XOR-ing:
* generate two random number, encode them into the cards, the actual secret is the XOR of the two numbers;
* K out of N is possible (I've seen some articles / StackOverflow posts), similar (though not quite exactly) to how RAID5 handles data;
I enjoyed the brevity of the python snippet required for this:
python -c '_secret = "d74ae47dc6f599d3f9cb847bd77d6b7c" ; print (bin(int(_secret,16))[2:])'
The only one minor issue with this snippet (which I now just realized), is that if the secret has the first few bits on zero (i.e. anything that starts with something under `7`) then the resulting bits would be less than 128, and thus the user has to copy them from right to left (the least significant one) on the card from bottom-right upward.
Alternatively, one could use the `.rjust(128,"0")` to pad the bits, as in:
python -c '_secret = "d74ae47dc6f599d3f9cb847bd77d6b7c" ; print (bin(int(_secret,16))[2:].rjust(128,"0"))'
Surprised no one has mentioned Cryptosteel.
https://cryptosteel.com/
Like this product, there are many other products that focus on allowing one to back-up crypto-currency wallet seed phrases.
However, they all have in common the following major disadvantages:
* cost -- I can't see myself paying 50+/100+/150+ EUR for such a product, no matter how fancy is the marketing;
* they are meant primarily to encode ASCII passphrases, thus they have low information density; (most formats allow one to encode only one letter per column;)
* size / format -- I want something easily portable, not a large slab of metal, or a heavy paper-weight; (thus I've used the standard CR80 ID card size;)
It's so stupid, I love it. I wouldn't personally use this format but maybe rather just... Print the text on the slate.
Provided that the information one wants to keep safe is sensitive and important long term, there are two main issues with printing (either text, QRCode, or anything):
* (paranoia) can you trust your printer not to leak the secret? (either in local memory, or to send it to its cloud mother-ship?) you can encrypt your information and print that, but then you are back to square one: where do you backup the password;
* and most importantly, long term resilience: given that with normal printers you can only print on soft materials (like paper, or perhaps plastic), they won't last floods, fire, and other unlikely events; (even if one laser etches some information on a steel sheet, I don't know how resistant to abrasions it is;)
However, by actually drilling holes into a metal sheet, the only way to permanently make the data irrecoverable, is to destroy the object completely.
For point 1 I recall the creator of Age, Filippo Valsorda suggesting something similar:
>The .age-recipients files also include the public key for an offline disaster recovery key. I generated the key with age-keygen, encrypted it with age -p, printed the ciphertext as a QR code, and wrote the random passphrase in pen. This is a bit convoluted, but I don’t trust printers. All this was done in a tmpfs, so nothing reached storage. Only had to do this once, and have been using that key as the anchor for all my disaster recovery data. https://words.filippo.io/dispatches/passage/
Or drill more holes.
Cool but wouldn’t you forget how to decode it after some time? I.e. wouldn’t engraving regular characters be simpler?
> Cool but wouldn’t you forget how to decode it after some time?
Not necessarily.
First of all there isn't much decoding to be done: if one follows the recommendation, and one uses the hex input variant as the password (or secret), then decoding is as simple as just writing the number is binary base. For example this password `d74ae47dc6f599d3f9cb847bd77d6b7c` can be recovered by simply starting a Python interpreter and writing `"%032x" % b1101011101001010...`
Moreover, by just providing the card to a computer science graduate / enthusiast, his first hunch would be to just try to convert the bits into a number and use that (either base10 or base16), perhaps after rotating / flipping the card (if he didn't knew about the alignment). (This can easily be deduced because there are 2 groups of 8x8 bits.)
(Alternatively, if one scratches on the card the URL `purl.org/999/1`, provided Archive.org, which currently hosts PURL.org, doesn't delete the links like Google just did with `goo.gl`. I intend to update the redirect from this PURL to a page hosted by Archive.org.)
> I.e. wouldn’t engraving regular characters be simpler?
The first, and perhaps greatest issue, is that not many people have access to engraving hardware. One could go to a shop and have the characters engraved, but then they wouldn't be secret.
So, the main purpose is this: how could one with minimal access to power or precision tools, create the sturdiest physical backup of a small piece of information.
Thus this proposal: with a sheet of metal, a nail, and a hammer, one could just encode the 128 bits by banging with the hammer on the nail through the sheet of metal. :)
Makes sense.
Perhaps one could engrave without specialized hardware, i.e. increase the nail and hammer dpi resolution a bit, use a pixel font and become a human dot matrix printer.
But yes, punch card decoding may be not a problem and a punch card could be fine too - and definitely much cooler.
You could laser etch redundant instructions on the back of the card. Sure, a few particular pieces of information might be punched out, but should be enough guide posts to reconstruct the encoding.
More data loss, harder to create.
Punch cards are stupid reliable.
Looks like a new 2d barcode format to me. Why I would want this rather QR or any other that have redundancy built in?
Besides the issue with printing and paper longevity, another issue with QRCodes is that you can't easily convert them back to data without a proper application that implements the decoding algorithm, and thus you need to extend your trust to the application you use to recover the data.
However, with the proposed format (which is in fact just the oldest storage technique in computer history), one can just use a pen and paper (or any dumb 70s calculator) to easily convert the backup into something usable.
For example: group 4 bits together, and compute `b1*8 + b2*4 + b3*2 + b4` to get the index of a hexdigit; write that down choosing between `0-9a-f`; move to the next group; and that's your password.
I can think of a couple of advantages. For one, punching these holes takes time (and physical space on the object), and a high-redundancy QR code’s extra holes don’t gain you much: instead, this approach situates the redundancy in the physical properties of the object itself.
For two, did you see the encoder/decoder script? Barely two lines of python! Which truly are optional, I guarantee many people here could encode and decode that pattern by eyeball. I know one can hand-calculate a QR code, but why would I when I can use raw bits?
There really should just be some ui for quickly typing out the stream of 1s and 0s row by row instead of clicking checkboxes.
There is:
* press `reset` (to clear the checkboxes);
* press `tab` (to select the first checkbox);
* if the current bit is `1` (i.e. there is a hole in the pattern), press `space`;
* move to step 2 (i.e. press `tab`);
Numbered array from 1...
Initially the bits were counted from 0, however this had two issues:
* using 0 as starting point would immediately trigger one's "computer science" instinct, and then it's uncertain which bit is actually bit `0`? the least significant one (as is in most cases), or the most significant one?
* by using 1 as the starting point, I hope would induce most people to just use it as a counter to number things in the "normal" (for westerners) left-to-right top-to-bottom, thus encoding / decoding is more "natural";
Absolutely makes sense. I have a 1960s desk tchotchke paper tape punch and I am tempted to cut my password store keyphrase into a tape in 7 bit ASCII with checksum as a super-encoded string, and then put it in the tombstone letter with the USB stick and instructions for decoding running the home filestore. A friend has a 3D printer and I think a small optical (light behind) reader and a decode table print might do the trick. There is the sprocket holes in paper tape but the weakness is driving things, and the tape roll is now 5 decades old, so the risk of a tear is there.
I'd do it in my stash of hollerith cards, but I don't have a desk punch. I suppose I could simply take some of the pre-punched ones, and use them as the key phrase!