ciprian_craciun

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";

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:

python -c '_secret = "d74ae47dc6f599d3f9cb847bd77d6b7c" ; print (bin(int(_secret,16))[2:].rjust(128,"0"))'

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

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.

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

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`);

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

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.