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;)
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!
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:
> 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.
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.
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.)
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.)
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;)