Hacker News Reader

Comment by hasenj | Hacker News Reader

How does public-key authentication work? Over things like, ssh, I mean.

Does the client send the private key to the server for verification? I'm not sure but I doubt it. At least I hope that's not what it does.

My guess would be that the server sends an encrypted message of some sort that the client cannot decipher unless it possesses the private key. It deciphers the message then sends it back to the server in deciphered form to say: hey, see, I have the private key, here's the proof: this is the message you sent me earlier. I couldn't have deciphered it without having the private key.

Can this scheme be used with passwords as well? As in, treat the password as a private key, so the client never has to send it over the network.

    Server ---- [garbled-message-challenge] ---> Client
    
    Server <--- [ungarbled-message-response] --- Client

Does this scheme work?

View on HN

Start here:

https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exc...

Seems to be talking about encrypted communication.

I'm talking more about authentication over a channel that's not necessarily encrypted.

The point being, avoiding having the client send its "secret pass word" to the server, but still allowing the server to verify the identity of the client.

Diffie Hellman is the cryptographic standard solution to "share a secret (and thus authenticate) over an unencrypted channel".

It's also what SSH uses.

Hope that's helpful!

The point is doing without sharing the secret.

I don't want to share my secret with you. You just throw a test at me that only I could possibly answer.

The point is, every time you should throw a completely different test at me.

Not only you can verify my identity, but anyone who's listening to the conversation can also verify my identity, and I don't have to share any secret.

That's the point of Diffie Hellman. Look at the paint can diagram on the Wikipedia page; a lot of people find it helpful.

Yes, once you've done a DH exchange, you can use the established key to relay a nonce to prove both sides have the same key.

The secret that's being shared with DH is thrown away and generated brand new every time you start a new session. Your private key is never shared with anyone. The term shared secret refers to material that is totally unrelated to a private key.

The ideal answer is a zero knowledge exchange. https://en.wikipedia.org/wiki/Zero-knowledge_proof

But tptacek obviously knows what he is talking about.

I... disagree about the obviousness of his expertise.

There's a lot of dazzle and he seems to be going out of his way to confuse people, or he is himself confused.

See again: Diffie Hellman. :)

In SSH's case public-key authentication simply involves signing datastructure that depends on the initial DH exchange. This does away with need to exchange some additional challenges and also binds the authentication to the encrypted channel.

Canonical protocol that involves generating (in this case symmetric) keys from passwords is Kerberos. Implementing same idea with asymmetric crypto is certainly possible, but of somewhat questionable utility, because doing ephemeral DH and then some kind of authentication handshake is both more secure (PFS and so on) and more efficient. True asymmetric encryption algorithms (e.g. RSA) have ciphertexts of considerable sizes (in comparison to anything ECC or sizes of DSA signatures), while discrete-log encryption algorithms essentially involve doing the DH exchange anyway.

In other words: asymmetric encryption is rarely the right primitive for network protocols. On the other hand converting password to keypair that is used for signing or something like SRP is useful for some applications (for most applications there isn't any practical benefit).

Reply on news.ycombinator.com