PunchCard Key Backup
29 points by ciprian_craciun
29 points by ciprian_craciun
Really cool project. I think this is just a nicer way to store the key to a password vault / private key in my safe deposit box, rather than a sealed envelope / smart key.
Not sure what problem it solves, but I like it. The GitHub README goes into more depth and makes it clearer that it’s meant to be punched out of metal for durability, which is something I missed the first time reading. I’m trying to come up with a relevant threat model (and I’d be curious to hear why the author built it for themselves): the scenario I’m imagining is I want to back up key material, I don’t trust digital systems to not be compromised, and I want more durability than just writing it on a sheet of paper (e.g., a secret I can physically bury).
Also, nice use of alignment holes to make sure it’s flipped the right way around!
(Author here) I’m glad you’ve liked my rehashing of (according to Wikipedia) the 18th century idea of punch cards.
The general use case is this: you have a secret that you want to make sure it survives mishandling, neglect, or unlikely events such as fires / floods.
An concrete example of such a secret might be a password to one’s personal backups (or “cloud storage” accounts), especially those media artifacts that have sentimental value for family and friends (like photos, videos, document scans, etc.)
You can distribute such metal encoded copies of the password to a few trusted family members and friends, then you can freely mirror your encrypted backups, together (both for the metal password and the backup) with a piece of paper that describes how to recover the password. (Obviously, you should keep the passwords and backups separate, and one could employ some secret sharing scheme to make sure a quorum of trusted parties is required to recover the key. But this is another topic.)
It might seem that the password might outlast the backup disk due to the different sturdiness / resilience profiles, however, the long term password backup is meant to be put in a safe place and and left alone undisturbed (until needed), meanwhile the backup disk is meant to be constantly swapped or refreshed, thus needs to be in a much more accessible place.
Before reaching to this solution, I’ve tried a couple experiments:
Thus, I’ve turned to the “crypto-coin” world to see what solutions they propose for backing up seed phrases: to my astonishment there are countless 50+/100+/150+ EUR products that offer one a steel tablet and punch tool to encode the first 4 letters of each seed phrase (from a known dictionary)… OK, I can do better I’ve said, why not punch raw bits, and here we are. :)
Why 128 bits? AES (which is still in use, and still considered safe) has three key sizes, 128 bit, then 192 and 256.
Thus, 128 bits are still cryptographically “safe” (at least for symmetric encryption), and they fit nicely in a standard CR80 ID card sized sheet of metal, while allowing one to drill 1 mm holes without compromising the metal resistance.
If one needs more than 128 bits, one can just encrypt that information with a truly 128 bit random password, and apply the same scenario as the above one (for personal backups). (Or for example create an Age / GnuPG secret key and protect it with the 128 bit password, and use this secret key to encrypt the data.)
Alternatively, 128 bits is still plenty safe against brute-force attacks, thus one could use a PBKDF or HMAC to derive as many secrets (and as long) as they need, from just a 128 bit seed. (One could even deterministically derive RSA or X25519 secret keys from a known seed.)
Depending on how risk-averse and future-proof you want to be, you might want to consider a 256-bit variant/extension.
Disclaimer: I am very far from an expert in quantum computers. But I’m vaguely aware that in a post-QC world, Grover’s algorithm could speed up brute-force attacks by a factor of O(sqrt(n)). So using 128-bit keys might only give you a 64-bit classical security level. Even if you use those 128 bits to encrypt a larger key, someone could theoretically brute-force starting from the smaller key until they found something that decrypts your data.
Grover’s algorithm isn’t actually a problem, because it’s inherently sequential. NIST estimates that a quantum circuit to break AES-128 would need to be 2**170 / MAXDEPTH gates big. MAXDEPTH is a guess for how long a quantum circuit can run, measured in circuit depth rather than time. NIST’s highest figure for MAXDEPTH is 2**96, which is “the approximate number of gates that atomic scale qubits with speed of light propagation times could perform in a millennium”. Much more realistic figures are in the range of 2**40 to 2**64. If we go with the worst case, we get 2**170 / 2**96 = 2**74, or about 19 billion trillion. Cerebras’s super duper big AI chip has 4 trillion transistors, 9 orders of magnitude less. And quantum gates will probably never be easier to build than classical gates.
I have a friend who is very concerned about the durability of his backups. Most of what I have, I don’t really care if it survives me, but he is meticulous about documenting and organizing, wanting the backups to last for dozens to hundreds of years.
At least a decade ago, he used a very similar scheme, he found a place that cut custom business cards and had one made out of (titanium or some nasty strong steel, I can’t remember) that literally cut out the hex characters of his encoded secret. The idea was he could keep an encoded password on him, so that even if he was in a terrible accident and he had his primary laptop and phone with him and they got destroyed, he still had enough information to access his off-site backups. The idea being the metal was tough enough that even in a strong fire it would retain its shape and give him a chance of getting back into his data.
I always debated the usefulness of 98% of what I have backed up to anyone other than myself, but hey, he was the one that put time into the infrastructure, so it was his call.