Show HN: PunchCard Key Backup

Thus defeating the entire purpose! Unless you plan to wipe your router's firmware after every one.

[dead]

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

Agree, going from binary to a higher base, e.g null, hole, + and -, would increase information density drastically (in 256 times in this case).

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.

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.

Can you describe those obscure vulnerabilities?

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

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

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

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

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.

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

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.

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