Thread

1. bzmrgonz · 1789618128 · focus · HN ↗

   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.

   1. morsch · 1789623646 · focus · HN ↗

      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).

      1. throw0101c · 1789651513 · focus · HN ↗

         > Think about it, the key analogy is just terrible.

         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.

         1. TeMPOraL · 1789661189 · focus · HN ↗

            The problem is arguably the symmetry in asymmetrical encryption - namely both "private" and "public" key are the same thing; the labeling "public" vs. "private" reflects your arbitrary choice of which of one you give away, and which one you keep for yourself.

            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.

            1. SoftTalker · 1789661475 · focus · HN ↗

               We did/do have that kind of lock: A safe deposit box at a bank. To open it, you need two keys, one of which you have and one of which the bank has.

               1. TeMPOraL · 1789661897 · focus · HN ↗

                  But that's the "you need two keys at the same time" case, which is different. I'm talking about "each of them can lock alone, but once locked, only the other one can unlock".

                  The real problem is that lock and key is a fundamentally dumb analogy for a process that scrambles something.

Unofficial Hacker News client; not affiliated with Y Combinator.