5 ms·

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

by hasenj 11y ago

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?

tptacek 11y ago
Start here: https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exc...
- hasenj 11y ago
  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.
  - tptacek 11y ago
    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!
    - hasenj 11y ago
      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.
      - tptacek 11y ago
        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.
      - chongli 11y ago
        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.
  - Pharaoh2 11y ago
    The ideal answer is a zero knowledge exchange. https://en.wikipedia.org/wiki/Zero-knowledge_proof https://en.wikipedia.org/wiki/Zero-knowledge_proof But tptacek obviously knows what he is talking about.
    - tptacek 11y ago
      See again: Diffie Hellman. :)
    - hinkley 11y ago
      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.
dfox 11y ago
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).

by hasenj 11y ago

tptacek 11y ago

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

hasenj 11y ago
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.
- tptacek 11y ago
  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!
  - hasenj 11y ago
    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.
    - tptacek 11y ago
      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.
    - chongli 11y ago
      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.
- Pharaoh2 11y ago
  The ideal answer is a zero knowledge exchange. https://en.wikipedia.org/wiki/Zero-knowledge_proof https://en.wikipedia.org/wiki/Zero-knowledge_proof But tptacek obviously knows what he is talking about.
  - tptacek 11y ago
    See again: Diffie Hellman. :)
  - hinkley 11y ago
    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.

dfox 11y ago

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