The OP itself and the title given here uses confusing language that isn't helping.

"Recovering the signing key", the title suggested by HN submitter -- I would not call the public key a "signing key". I might call it a "verification key". You can not recover the "signing key".

The author of the OP: "ECDSA has a specific cryptographic property that given a signature and the message it signed, you can mathematically recover the public key that produced it" -- no, the "public key" did not produce the signature!! If you could actually recover the private key that was used to produce the signature, that would mean that ECDSA was fundamentally flawed in it's very fundamental design, and it is not, in this way anyway. You could say "public key that can be used to verify it", or "verification key that goes with the private key used to sign it", or anything different from what they said.

This stuff is confusing for people who didn't learn it long ago, and people who should know better using incorrect and/or misleading language does not help here! Just say "public" and "private", the actual standard terminology. if you aren't sure how to decribe them more transparently, these already at least describe which key is intended to be secret and which isn't! -- calling the public key a "signing key" or "a key used to produce the signature" is just wrong.

Think about it, the key analogy is just terrible. In the origin domain, losing a key is always bad, and making a key available to all is a non sequitur.

It's not like non-technical people understand asymmetric cryptography. Or even technical people, for that matter.

Maybe we should refer to the public key as an address, and the private key is just a password again. You can send stuff, securely, to an address. And you can verify the sender when you have their address (ie check the signature).

That implies they chose not to. More likely the other states simply didn’t realize the value derived from paying a vendor to enable a ‘feature’, not realizing both the necessity of such signatures and that the cost to the vendor and mechanism of delivery is precisely the same regardless. One might consider what sort of pressures a citizen could apply to compel those states to act more to their own benefit, but I have no specific ideas to suggest at this time.

I think it depends on the context? It's in an ID card's design goals to be provably valid, so it's pointless to not publish its public keys, but something like SSH pubkeys, uhh, should I really be so eager to just publicly dump all of mine…?

Where did you get the impression the author thinks it’s a bad thing? From the article:

> These are public keys, which are meant to be published - recovering one lets anyone check a signature, not forge one.

its even called "public" lol

> Seems doubtful! I expect the forgers used a real signature from another card instead, so it has the right key but the wrong data. Reverse engineering the process as the author did and making up their own key wouldn't be of any value to the forgers.

This was just bad wording. I meant to say "someone else's key" in the context that it was a key generated by the forgers rather than the state DMV, will update to make it more clear!

> This is not wrong, but should come with a little warning. A real verifier needs to additionally check the encoded data matches the human-readable data on the front of the card.

Correct, but simply checking that it matches the front is likely not enough to deter fraud. You could extract the barcode data from a real ID and put it on a physically different (fake) ID with a different photo and it would still return as valid. To detect this you generally would need a higher end solution (IDScan.net/VeriScan's ID authentication solution (yes... the one that just leaked everyone's data), TokenWorks' IdentiFake, IDScience, amongst others) that does the same high resolution UV/IR checks TSA does. But the forgers are good enough now to be able to sometimes pass those scanners too.

most bars have scanners that will warn if the same id is scanned twice. it means that someone producing fake ids would at least need a repository of valid barcodes such that two purchasers wouldn't experience the birthday problem trying to get into a bar.

> A real verifier needs to additionally check the encoded data matches the human-readable data on the front of the card.

I mean, not really? Only the machine-readable part is signed, so it should be treated as the sole source of truth. Besides, only an idiot forger would put different data in the human-readable part - it would be the easiest way to get caught!

What are you talking about. ZNB field data related to nothing youve mentioned. Stands for zuck my balls. Haha.

dog out.

-dog22212

Yes. The subtitle is wrong. He recovers the public key, due to the way EDCSA signing works.

Yup. The person who submitted this to HN is probably way less knowledgeable on this topic than the writer of the article. The article clearly labels the recovered keys as “recovered public keys” at the top.

> The signature doesn't even cover the photo!

Which makes sense, as the signature is for the barcode data...

IIUC, the forgery path then involves getting any legitimate California license and changing the photo only? I guess that works.

And it's a classic case of Not Invented Here as well: this problem was solved decades ago and the solution is widely-deployed in passports and most European identity documents - just use NFC!

Cryptographic NFC chips are basically free these days, and any modern smartphone can read them. The photo issue is solved by having the chip contain a copy of the photo, as a few extra kilobytes of data isn't an issue when you aren't using barcodes. The copy issue is solved by having the chip sign a verifier-provided nonce together with the data, and having the government sign the chip's public key instead.

You can only store ~1100 bytes in a PDF417 barcode so storing the image itself it unfeasible. And storing a signature of an image you don't have access to is useless. Passports are able to do this because the smartcard chips they use can store at least 32 KB of data (usually more).

The Austrian ID card does that. It’s a really blurry black-and-white photo only, but it’s still recognizable and I find it quite impressive that any type of photo (in addition to its public key signature) can fit into a QR code at all.

I wonder if we might have the equivalent of Certificate Revocation List for IDs leaked this way.

Walk into bank? The last time I opened a bank account (2023), I tapped my driver's license to my phone, it got my details+photo via NFC, I took a "liveness check" video and was onboarded. This has been the workflow for many years now for consumer account openings, or installing a banking app on a new phone. I think bunq did it first around 2017. As soon as (EUDI) wallets are more standardized, both neobanks and high streets banks will adopt that too.

> there are some gaps in that chain

for example, a reliance on apple wallet, instead of an open standard.

With that quibble aside, I do like the basic structure of your solution.

> Very soon we are going to be in a world where you walk into a bank to open/maintain an account

I've never in my life walked into a bank to open a bank account. I've got accounts with many different banks these days. Real banks and credit unions, not fake neo banks.

The only times I've ever been in a bank was to get large denomination ($100s) currency, as most ATMs around me don't dispense those. And most of the time I didn't even bother going into a bank I had an account with, most will let you get cash for free with a debit card even if you don't normally do business with them.

The main idea in this that scares me is trusting the State of Alabama (e.g.) to protect their private keys. Humans tend to be the weak links in all of these chains.

My elderly parents and some of my technology illiterate coworkers are going to hate that with a passion.

“But my phone isn’t a wallet. My wallet is a wallet.”

Louisiana has one but I’d be shocked if it was up to date with the latest in crypto having met the company owner.

The first thing I do with a real ID is widen the reference bars on the sides so the checkout scanner can't read it. If they want my birthday they can type it in manually, I don't need all my info in some store database.

The other thing I remember was California fakes folding in half and not breaking

Looks like the criteria were 1. No cost to the government/taxpayer. 2. Minimal work for the civil service.

Thank you! Just updated it to use the the browser default monospace for inline text.

I loved that pixelated mono space font. It’s a personal site; the author is allowed to have some whimsical elements and not conform to your readability standards. You can always change the font yourself in the browser.

The analogy is right there in the name: Signatures.

But rather than identifying forgeries by inspecting the handwriting details and ink pigments or whatever, we have math.

How it works in my state: For in person renewals/changes, they punch VOID into your old license, give it back to you, and give you a temporary license printout. Then your new license is mailed a couple weeks later.

For remote renewals/replacements, they just give you a temporary license to print out and then mail you a new one. The old license never gets physically cancelled.

I lost my old one, so ordered a replacement. Later I found the lost one, so I have two... The number is different, though, so I'm sure the old one is invalidated in the database. (Oregon)

I got a temporary license and received the real one in the mail later. Yes, you can keep the old one.

Copy known good serial number + signature.

It’s a bunch of static signed data, which is hard to modify but trivial to copy. Not exactly what you’d want for bank notes.

NFC and a challenge-response protocol could work, though, like e.g. the one used in biometric passports.

As far as compact encodings go, this kind of patch-and-fill technique isn't particularly egregious. The alternative mentioned (where the verifier has to be aware of a bitfield that defines the to-be-signed elements) is much easier to mess up!

Counterpoint - every real world crypto algo needs to do somewhat content aware padding or the crypto is much easier to break. Either that, or go so overboard on randomness that it adds a lot of overhead.

When you look at the details underneath more crypto, there is a lot of ah hah - and ‘doh’ - moments due to implementation realities.