[HN Gopher] Show HN: PunchCard Key Backup
___________________________________________________________________
Show HN: PunchCard Key Backup
Author : ciprian_craciun
Score : 91 points
Date : 2025-05-31 16:09 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| Mraedis wrote:
| It's so stupid, I love it. I wouldn't personally use this format
| but maybe rather just... Print the text on the slate.
| ciprian_craciun wrote:
| 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.
| fhars wrote:
| Or drill more holes.
| qyckudnefDi5 wrote:
| For point 1 I recall the creator of Age, Filippo Valsorda
| suggesting something similar:
|
| >The .age-recipients files also include the public key for an
| offline disaster recovery key. I generated the key with age-
| keygen, encrypted it with age -p, printed the ciphertext as a
| QR code, and wrote the random passphrase in pen. This is a
| bit convoluted, but I don't trust printers. All this was done
| in a tmpfs, so nothing reached storage. Only had to do this
| once, and have been using that key as the anchor for all my
| disaster recovery data.
| https://words.filippo.io/dispatches/passage/
| msk-lywenn wrote:
| Looks like a new 2d barcode format to me. Why I would want this
| rather QR or any other that have redundancy built in?
| ciprian_craciun wrote:
| 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.
| alwa wrote:
| 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?
| cypherpunks01 wrote:
| Nice! 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.
| ciprian_craciun wrote:
| 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.)
| rubyfan wrote:
| Reminds 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.
| im_down_w_otp wrote:
| I 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.
| stavros wrote:
| Thus defeating the entire purpose! Unless you plan to wipe your
| router's firmware after every one.
| ciprian_craciun wrote:
| 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.
| stavros wrote:
| Sometimes CNC machines are networked, sometimes not, but
| the idea behind saving keys like this is that you only
| generate the appropriate bits on disposable computers, e.g.
| a Raspberry Pi with an SD card you can then destroy.
|
| It depends on how much money you want to secure, of course,
| so YMMV.
| im_down_w_otp wrote:
| The CNC router's firmware? The CNC controller itself is dumb
| as hell. It's connected via serial to an old offline computer
| that's only job is to pipe G-code over RS-232. Not even to
| "load a program" to hold in memory on the controller.
| Literally to stream the commands to the machine.
| stavros wrote:
| My CNC controller has an SD card, Wifi, Bluetooth, and USB.
| They're not all the same.
| kens wrote:
| Just 128 bits? I expect punch cards to hold 80 columns of 12 bits
| :-)
| ciprian_craciun wrote:
| 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.)
| 3eb7988a1663 wrote:
| 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
| deadbabe wrote:
| There really should just be some ui for quickly typing out the
| stream of 1s and 0s row by row instead of clicking checkboxes.
| ciprian_craciun wrote:
| 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`);
| thih9 wrote:
| Cool but wouldn't you forget how to decode it after some time?
| I.e. wouldn't engraving regular characters be simpler?
| vorpalhex wrote:
| More data loss, harder to create.
|
| Punch cards are stupid reliable.
| ciprian_craciun wrote:
| > 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. :)
| 3eb7988a1663 wrote:
| 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.
| neilv wrote:
| I like the survivability, and the constraint to be doable with
| common hand tools.
|
| For more information density, and easier readability by a less-
| technical person who inherits it -- at the cost of requiring
| special tools -- I wonder about using number&letter stamps with a
| hammer.
|
| Or, if you permit very special tools, laser-cut alphanumerics
| (base16, base58, or base64, for arbitrary bits; or alphabetic
| passphrases). Either engraved, or cut fully through, like an old
| drafting lettering stencil.
| ivanjermakov wrote:
| Agree, going from binary to a higher base, e.g null, hole, +
| and -, would increase information density drastically (in 256
| times in this case).
| throwanem wrote:
| Make sure it's stored in an electrochemically inoffensive
| environment, including considerations like dissimilar-metal
| contact, etc. Aluminium is a good choice here especially for
| being both easily worked and self-passivating in air, but it has
| some more obscure vulnerabilities which can have impact over
| decades.
| QuadrupleA wrote:
| Wouldn't printing a QR code be way easier? If it's just for retro
| fun / Rube Goldberginess than nevermind, carry on :)
| econ wrote:
| 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...
___________________________________________________________________
(page generated 2025-05-31 23:00 UTC)