"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.
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.
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.
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.
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.
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.
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.
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.
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.
- 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.
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.
> These are public keys, which are meant to be published - recovering one lets anyone check a signature, not forge one.