"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.
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).
The public counterpart is tricky to name but I think attaching "public" to it makes the intended usage plenty clear. There isn't really a physical counterpart unless you consider maybe those machines that check for counterfeit cash but even that's not a great fit because the pubkey is simultaneously analogous to a lock box.
Because originally it was not really that much of an analogy: we only had what is now called "'symmetrical' encryption", but was just "encryption" back in the day (dating back to even Caesar perhaps). So the 'key idea' made complete sense: don't lose the one thing that could unlock things.
It was only more recently (in the relative, historical sense (~1970s)) that public and private "keys" became a thing, and the differentiation between symmetrical and asymmetrical encryption was made/invented.
While this works for encryption, it doesn't really work for explaining signatures or however. Maybe someone can come up with a good analogy for that case.
- If you install such keys to a host, and an attacker (with access to said host) has catalogued your ssh keys, they can see that you have access to said host (if they can correlate your method of publishing the keys to your identity)
On the other hand, if you go to the other extreme (?), you can have a different public ssh key per host. This way the server owner/attacker is not able to correlate that ssh key with other keys to recover your identity. (You need to take care that ssh won't offer too many public keys in that case.) Example case of a service that might get offered many ssh keys: github.
Personally I don't bother. But I wouldn't be too bothered about just putting my public keys to some "secret" URL in the internet either, so I can easily enable myself ssh access to a host with a single curl.. Maybe I should indeed do that.
> These are public keys, which are meant to be published - recovering one lets anyone check a signature, not forge one.
> the ZNB field is not empty and not garbage: it contains a well-formed 71-byte DER ECDSA signature, correctly Ascii85-encoded, with the right prefix and a plausible length. But it fails the cryptographic check instantly, because it was signed with somebody else's key.
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.
> I built a little demo to check the signatures across California, New York, and Virginia: take a picture of the barcode and check it here.
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.
recovering the signing keys for US driver's license barcodes
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?
That's not what the signature guarantees, though. It says the combination of textual information on the card is *someone's* valid driver's license. The signature doesn't even cover the photo! It just limits the forgeries to using identities of real people.
Compare to https://en.wikipedia.org/wiki/Biometric_passport that actually contains a digital photo, with a signature.
Which makes sense, as the signature is for the barcode data...
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.
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.
Having the photo there just encourages sloppy ID checks by human eye, and it's much easier to mislead the human eye than it is to forge an NFC chip.
If the photo was in the chip only, we'd force ID verifiers to do their job properly, and make forgeries structurally impossible. With basically everybody having an NFC-enabled phone now, you wouldn't even need people to get extra hardware for this.
1. The bank emails/SMSes the customer a link
2. The customer takes out their iPhone, opens whatever email/messaging software & taps the link
3. The link takes the customer to a specially crafted page owned by the bank that triggers a native OS process for opening Apple Wallet and gathering requested ID details with consent.
https://developer.apple.com/videos/play/wwdc2025/232 https://www.w3.org/TR/digital-credentials
This is potentially a superior arrangement because it could eventually establish a strong cryptographic chain of trust all the way to the issuer (e.g. the State of Alabama). Right now there are some gaps in that chain but I see no reason they couldn't be closed over time.
Digital verification is going to matter a lot more for objects we own rather than the objects that proxy for that (currently the main function of an ID). Identity fraud is only problematic because ownership is tied to a loose record of SIN/DL.
Having a physical medium represent ownership just shifts the burden to the state and allows for social engineering and fraud to persist.
Of course passports are expensive and not everyone has them, but if you do, next time you renew, opt for the book+card option.
[1]: https://www.dailystar.co.uk/news/latest-news/digital-id-upda...
..
When discussing asymmetric cryptography with less technical folk, a lock analogy breaks down quickly as locks are conceptualized as being symmetric. Hence, "key" is a poor word that came from symmetric cryptography; one really needs to discuss the signature or authentication code.
A better analogy may be a transparent display case, where only authorized people can put things into the case. To check a copy outside the case is true, one would want to go to the official display case and compare. This isn't a great analogy because there's no analog to the signature, but it gets the asymmetry across.
Perhaps we might do a bit better? Suppose your friend gave you a poster copy of a famous painting from the Metropolitan Museum. On the poster is the curatorial accession number. You could go to the MET and check if your poster matches the painting, which should have matching accession number on the label.
So far our analogy covers asymmetry but is still centralized. The museum also distributes a catalog of its posters/paintings. Catalog entries have a thumb print of the painting and its accession number. So, if you could find a trusted copy of that catalog, say at your local library, you might also use this to check the painting's authenticity without having to travel to the museum. Alas, this analogy fails since the whole catalog need not be shared (just the public key).
These analogies are still problematic. This is an involved and novel cryptographic process, and for the interested policy maker or their trusted advisors, it's probably much better if we teach the real process with worked examples.
But rather than identifying forgeries by inspecting the handwriting details and ink pigments or whatever, we have math.
I have to surrender my old license to the person in the room. How does that work if your license is mailed to you? Do you get to keep the old one?
(Delaware)
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.
My licenses have always been printed on a plastic card, but I remember seeing older licenses that were basically laminated photo paper.
NFC and a challenge-response protocol could work, though, like e.g. the one used in biometric passports.
I can't imagine Illinois, where I live that I believe uses IDEMIA from what I know about the Apple Wallet rollout wouldn't want to add this.
Time for a federal law banning the DMVs from outsourcing this stuff (or selling the bulk data like they do to insurers).
I hate shit like this. Do not let your crypto layer know about the structure of what it's signing. Keep security stupid.
When you look at the details underneath more crypto, there is a lot of ah hah - and ‘doh’ - moments due to implementation realities.
dog signing out.
-dog22212
It's surprising that we didn't invent any kind of physical padlock that accepts two keys, with the lock mechanism such that, when locked with one of the two keys, can only be unlocked by the other key. I can imagine obvious use cases for that, e.g. in shipping, but I guess this won't adopted because it makes the key management problem immediately obvious. But should such a thing existed, that would be the best (edit: just better - see my other comment explaining why "lock" is the dumb part here) analogy to draw terminology from.
Key exchange blocks are basically this, except one of the two keys is perpetually locked inside the keyblock, and you must use the other to retrieve it (whereupon the key you just used is now locked in the block).
So not quite the same thing, but the closest example I know of.
They do:
* https://www.youtube.com/watch?v=VAriLDgpnY8
As mentioned in the video they're usually used in commercial settings. Also:
> One Way Cylinder Keying: Allows for the issuance of one key that can ONLY lock, one key that can ONLY unlock and one key that can BOTH lock and unlock the cylinder. Perfect for applications where one key holder should only have authorization to lock, while another should only have authorization to open and yet another can have the authorization to perform both functions. One way keyed products are supplied with 2 nylon head cut keys per product and 1 key order card per product.
* https://mangionelocksmiths.com/wp-content/uploads/2017/02/Mu...
It is not quite arbitrary. With RSA, you could potentially store only the modulus and the exponents, publishing one exponent and keeping the other one private (or making each privately known to different people, with both having the modulus). However, the way it is commonly stored is with the private key file includes both exponents and several other numbers, and the public exponent is usually 65537 which makes it easy to guess so you cannot effectively keep it secret. With some other kinds of cryptography (other than RSA), you can figure out the public key from the private key even without doing things like this.
The real problem is that lock and key is a fundamentally dumb analogy for a process that scrambles something.
I don’t think there’s any process or entity in the physical world that is reasonably familiar to most people that is even remotely suitable as an analogy to public key cryptography.
I think the reason we (the HN crowd) don’t like it is that the analogy starts to break down when you start thinking through all of the operations you can do with public keys. But this does not matter much for somebody learning to use them for the first time. I’ve had to grow comfortable with the idea of giving people imperfect explanations so that they can build an intuition. Once that happens I can return with the mathematics so that they can really understand what is going on.
These are not analogs to things ordinary people had already seen. For Computation we just got used to it being everywhere and so we don't need to explain it so much.
IE; the existence of the asymetry allows for the public key to function more than just a "lock", but a much more easy to rationalize "signer attestation.
The analogy doesn't make sense because it's skipping the existence of the third thing that's the actual (pad)lock - the encryption/decryption software. And it does that because it wants to talk about data as having the property of being "locked", which makes no sense in the first place, but that one isn't immediately obvious.
The whole analogy of locks and keys fundamentally makes no sense when talking about data, because locks are external devices, attached to or directly containing the protected thing, while encryption is the process of scrambling the very thing being protected.
All confusion stems from this bad choice of analogy, trying to "make it simple" for the normies.
A single Security Key can authenticate to Facebook as WeedLover420 and then be used to sign into the Google account of the Secretary of the US Marijuana Task Force and even if both Facebook and Google were co-operating in the work there's no way to connect these authentications. Obviously WeedLover420 is more likely to get caught because they used the same IP address to do both things and they stink of weed and they look stoned all the time, but none of those are because of the Security Key, that was locked down good.
But if you need to be ID checked entering a club or just buying a beer… they’re not training for that, and they’re not buying the hardware to handle it automatically either. Looking at a photo is an appropriate level of security for that purpose.
Of course, only until the real DL arrives in the mail, which usually takes a week or two.
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.
ID chips can't be cloned, so you don't even need photo auth (unless you want to protect against stolen but real IDs).
An actual hard-to-clone chip to contain the authority to access the photo would be even better.
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!
If he pairs the edited human-readable part with a real barcode copied from a real license in someone else's name, then anyone inspecting the license will see the documentation matches his claim, and if they also use this site to check for fake barcodes it will confirm the barcode was really issued by the California DMV.
dog out.
-dog22212
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.
“But my phone isn’t a wallet. My wallet is a wallet.”
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.
It is true that publishing your private key is bad but you'd hope the name makes that pretty clear. Despite the way I remember (U2's "The Fly" lyrics, "A secret is something that you tell one other person, so I'm telling you, child") people generally do not understand that the whole point of secrets is that at least two parties know, which means you might always be betrayed by somebody you think is keeping your secret. For a private key it's easy, don't tell anybody, nobody knows, you can't be betrayed, done.
For example Hacker News learns my password to this web site every single time I sign in because that's just a secret. We've known how to do better for decades but only a handful of systems I use (e.g. Google) do so and all of them have a "traditional" password option which is like discovering your aeroplane still has a smoking section in 2026.
I don't know the details of the login system for Hacker News, but i would expect they learn "a hash of your password and some salt" for every login, and your password isn't just transmitted to them. If they're doing things correctly, they're only storing a hash of your password, and can't work backward to get it -- that's a big If, and lots of places get it wrong.
No. That would be a terrible idea and so that's not what they do. You can go see for yourself, it's an HTML form, the text field with your password in it is submitted to their web server, much in the same way this larger field full of comment text was sent.
If you think a bit harder you'll realize why your approach would be a bad idea. A bad guy who has obtained the password hashes (for example by dumpster diving, or an SQL extraction) can just play back a hash they've seen without ever knowing your password, you've rendered the knowledge of the password useless.
Yes, that means if you've been around long enough, sites which had passwords but did not use TLS or before that SSL, were sending your actual password, unencrypted, for any snoop to see. That might seem crazy, but because I'm an old man when I first used the Internet it was normal to send your password, letter by letter in plain text, to connect to a remote Unix machine. The "Secure Shell" you take for granted today did not exist until July 1995.
And if you think about it, there's really no advantage to sending the hash every time anyway. An attacker that MITMs your traffic once can just resend the static post-computed hash to the backend anyway.
The only advantage would be preventing an attacker from seeing a password string you may re-use for other sites, but so long as it's unique for HN alone (surely we all use password managers on here? :-) ) it doesn't matter.
The inability to betray is a sharp observation but I think the analogy still holds flawlessly. It's a physical lock that you haven't handed out the key for so you're the only one with access to it. However the public counterpart still defies easy explanation.
Why did you put "symmetric keys" in scare quotes? Is that not the common term in your neck of the woods when speaking about symmetric crypto?
Encryption scrambles the data. Key is the piece of information that lets the information be scrambled in specific way so that it can be unscrambled by someone in possession of the same (symmetric) or complementary (asymmetric) key.
The only "lock" in the whole thing is the scrambler (encryption software), and that one is usually publicly known and available.
Obvious way to make this clear: if "keys" were a lock, the original data in readable form would be there, accessible if you found a way to bypass or destroy the lock. The whole point of encryption as opposed to locking is that you cannot do this, because the data itself is scrambled - and thus you don't even need to ship any "lock", just the scrambled data, because the "lock" is something everyone already has or can procure.
This isn't true. If I do something privately by myself and never tell anyone it's still a secret. If I have a hidden compartment in my desk to hide things and I'm the only one who knows about it, it's a "secret compartment". A secret doesn't have to involve a second party at all.
E-cash depends on the secrecy of the signed data, and immediate redemption with the issuer once it's been spent/accepted. This is a terrible model for physical cash.
> immediate redemption with the issuer once it's been spent/accepted. This is a terrible model for physical cash
also the obvious way such cash would work is that "redemption" is just the new minting of coin. the central authority will mint a new coin by blindly signing your secret after you "destroy" the spent coin by giving them the unblinded signature.
> 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!
I don't see how any e-cash solutions can help here.
It's just much "too private" to get any political traction. At the very least, I suspect an acceptable modern alternative would either have caps on what can be sent/received completely anonymously (e.g. per recipient and timespan) or want non-anonymous recipients (to allow for VAT/sales tax accounting etc.)
ID chips can be manufactured, so they can obviously be cloned.
Thinking like yours leads to the asinine situation we saw ten, fifteen years ago where insurers were refusing to pay out vehicle theft claims because "There's no way to clone an RF keyfob or RF immobilizer chip!". Spoiler alert: There were many, many ways to do that.
For example a VPN connection lends itself to being described as a pipe. That already equates the encapsulating protocol with a physical barrier regardless of the presence of cryptography.
I think you're just being overly literal, something which will kill almost any decent analogy regardless of topic.
And it's because it does not fit. Locks and keys are distinct kinds of objects, and are external to the thing being protected, with lock itself being attached to the thing being protected. Only the key can be distributed separately and copied; you come into possession of the security mechanism and the protected object together, they're literally unseparable (that's the point - if you can separate the lock from the thing, you don't need the key anymore).
Encryption in contrast is (reversibly) destroying the thing being protected, the "locking mechanism" is public and same for everyone and therefore you already have a copy, and you can't "bypass" it because the very thing being protected has been destroyed (scrambled) and you cannot undo that without having the "key".
There's no 1:1 mapping of any concept from physical locks and keys to encryption. It's a fundamentally dumb analogy that people run away with, because at first look it seems to have some semantic similarities.
Of course for a website and assuming TLS then in practice it doesn't make much difference whether the hashing takes place client side or server side since an attacker sitting on the server could presumably serve up a compromised frontend. And without TLS a MITM could again compromise the frontend. But hashing client side does at minimum prevent the service operator from accidentally logging plaintext passwords, and anyway not all services are web apps. An attacker can't trivially change out the frontend if it's an app on my phone.