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

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.

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?

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

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

Edit: If my first search results are to be believed, the first magnetic hard drive had a density of 3.1 bits/mm^2

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

Punch cards are stupid reliable.

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

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.

> 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

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

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"))'

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