It baffles that people think it's a bad thing to disclose a public key. That's their purpose actually. Sure we now have the post quantum computer threat, and some state actors are harvesting keys, but quantum computer is going to disrupt so much, that Id verification won't even matter really.
All of this is nearly pointless unless the photo itself is in the barcode and also signed. You only need a leak of a few hundred real IDs to cover all of the identifiable characteristics (hair, eye, skin color, approx height and weight). Leak a few hundred thousand a year and now you can’t even flag leaked IDs without some false positives.
A fake photo plus a valid barcode will pass any current check right? Unless you still do a secondary proprietary photo lookup that I don’t think exists.
I had a fake ID, and it being scannable was a huge selling point. Convenience stores all scan, and don't seem to care if you look underage. I was only turned down two or three times, usually at bars and restaurants.
That's really neat! Seems potentially adaptable to paper currency--a verifiable QR code digital signature of the bill's serial number creates a cryptographically hard obstacle to counterfeiting!
At the time of this writing, the subtitle of the submission here on HN is
recovering the signing keys for US driver's license barcodes
Notably, this subtitle doesn't appear on the blog post.
Anyway. I only see claims that the public key can be determined from license barcodes, not that a signing key can be determined. What am I missing or misunderstanding?
To head off one potential retort: While it's true that one can use a public key to encrypt data for the recipient that has the private half of that key or verify that data has been signed by the possessor of the private half of that key, I'm almost 100% certain that it's not possible to use that public key to sign data would validate to other folks as being signed by the private half of that key. It has been more than a decade since I've thought about any of this, but isn't the entire point of public-key cryptography that the public part can be distributed to your worst enemy without causing you any trouble at all?
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.
> Before signing, the encoder fills the field with a placeholder (0), repeated for the field's exact length - signs the entire payload including that placeholder, and then writes the real signature over the top of it. To verify, you put the placeholder back.
I hate shit like this. Do not let your crypto layer know about the structure of what it's signing. Keep security stupid.
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.
It baffles that people think it's a bad thing to disclose a public key. That's their purpose actually. Sure we now have the post quantum computer threat, and some state actors are harvesting keys, but quantum computer is going to disrupt so much, that Id verification won't even matter really.
All of this is nearly pointless unless the photo itself is in the barcode and also signed. You only need a leak of a few hundred real IDs to cover all of the identifiable characteristics (hair, eye, skin color, approx height and weight). Leak a few hundred thousand a year and now you can’t even flag leaked IDs without some false positives.
A fake photo plus a valid barcode will pass any current check right? Unless you still do a secondary proprietary photo lookup that I don’t think exists.
I wonder if we might have the equivalent of Certificate Revocation List for IDs leaked this way.
I had a fake ID, and it being scannable was a huge selling point. Convenience stores all scan, and don't seem to care if you look underage. I was only turned down two or three times, usually at bars and restaurants.
The other thing I remember was California fakes folding in half and not breaking
I come to HN to learn things I never realized I wanted to know.
https://web.archive.org/web/20260917035309/https://ryan.scie...
That's really neat! Seems potentially adaptable to paper currency--a verifiable QR code digital signature of the bill's serial number creates a cryptographically hard obstacle to counterfeiting!
Copy known good serial number + signature.
At the time of this writing, the subtitle of the submission here on HN is
Notably, this subtitle doesn't appear on the blog post.Anyway. I only see claims that the public key can be determined from license barcodes, not that a signing key can be determined. What am I missing or misunderstanding?
To head off one potential retort: While it's true that one can use a public key to encrypt data for the recipient that has the private half of that key or verify that data has been signed by the possessor of the private half of that key, I'm almost 100% certain that it's not possible to use that public key to sign data would validate to other folks as being signed by the private half of that key. It has been more than a decade since I've thought about any of this, but isn't the entire point of public-key cryptography that the public part can be distributed to your worst enemy without causing you any trouble at all?
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.
Given the poster's nickname, the person who posted it and the author may be one and the same.
I think the author is Claude.
> Before signing, the encoder fills the field with a placeholder (0), repeated for the field's exact length - signs the entire payload including that placeholder, and then writes the real signature over the top of it. To verify, you put the placeholder back.
I hate shit like this. Do not let your crypto layer know about the structure of what it's signing. Keep security stupid.
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.