Show HN: PunchCard Key Backup
github.com
Show HN: PunchCard Key Backup
1–10 of 51 posts
Re: Show HN: PunchCard Key Backup
#2It's so stupid, I love it. I wouldn't personally use this format but maybe rather just... Print the text on the slate.
Re: Show HN: PunchCard Key Backup
#3Looks like a new 2d barcode format to me. Why I would want this rather QR or any other that have redundancy built in?
Re: Show HN: PunchCard Key Backup
#4It's so stupid, I love it. I wouldn't personally use this format but maybe rather just... Print the text on the slate.
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.
Re: Show HN: PunchCard Key Backup
#5Looks like a new 2d barcode format to me. Why I would want this rather QR or any other that have redundancy built in?
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.
Re: Show HN: PunchCard Key Backup
#6Nice! With a denser 256 bit card you could store an entire age secret key, and so encrypt any amount of data directly to metal key asymmetrically, only needing the public key at encryption time (keeps metal key safer).
Then thresholding can be done with "sops" (which uses the Hashicorp vault shamir implementation) against groups of age keys. Making it so M of N metal backups are required to decrypt the nuclear codes you're storing.
Re: Show HN: PunchCard Key Backup
#7Looks like a new 2d barcode format to me. Why I would want this rather QR or any other that have redundancy built in?
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?
Re: Show HN: PunchCard Key Backup
#8Nice! With a denser 256 bit card you could store an entire age secret key, and so encrypt any amount of data directly to metal key asymmetrically, only needing the public key at encryption time (keeps metal key safer). Then thresholding can be done with "sops" (which uses the Hashicorp vault shamir implementation) against groups of age keys. Making it so M of N metal backups are required to decrypt the nuclear codes…
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.)
Re: Show HN: PunchCard Key Backup
#9Reminds me of the physical keys we’d in the army. Though they were designed to not be long lasting, I think they were paper strips that could be burned after using mission impossible style.
Re: Show HN: PunchCard Key Backup
#10I love this so much. This, this right here is why I still visit Hacker News.
I'm going to use this today and pave a path to my CNC router to make it stupidly easy to generate these plates on-demand.