0

From SSH handshake process explained http://www.cathaycenturies.com/blog/?p=1635

Key Exchange

  1. The client has a public & private key pair. The server has a public & private key pair.
  2. The client and server exchange their public keys.
  3. The client now has its own key pair plus the public key of the server.
  4. The server now has its own key pair plus the public key of the client.
  5. This exchange of keys is done over an insecure network.
  6. The client takes its private key and the server’s public key and passes it through a mathematical equation to produce the shared secret (session key).
  7. The server takes its private key and the client’s public key and passes it through a mathematical equation to produce the shared secret (session key). Both these shared secrets are identical! This is an asymmetrical key.
  8. This encrypted tunnel is used for the remainder of the session, including the next phase: User Authentication.

Bullets 6 and 7 say that the client takes its private key and the server’s public key and passes it through a mathematical equation to produce the shared secret (session key), and the server takes its private key and the client’s public key and passes it through a mathematical equation to produce the shared secret (session key).

  1. They say that the server and client produce the shared secret i.e. session key and Both these shared secrets are identical. Does it mean that both the server and the client produce the same session key in the same session. If yes, why does it also say that "This is an asymmetrical key"?

    Does "This is an asymmetrical key" mean that the session keys generated on the server and client are not the same?

  2. Do bullets 6 and 7 mean that on either the client or the server, the inputs to the algorithm that generates a session key are its own private key, and the other one's public key?

    If yes, how are the session keys on the server and client identical, given their inputs are different?

    How are the session keys different for different sessions? Are there inputs that are session-specific?

I have read the reply by Jakuje at https://unix.stackexchange.com/a/290027/674, but am still not sure about how to answer the above questions.

Thanks.

2
  1. Does it mean that both the server and the client produce the same session key in the same session.?

Yes, as it is visible from the picture in the recent question.

If yes, why does it also say that "This is an asymmetrical key"?

No idea. You better ask a author of the article. Asymmetric cryptography is used to create shared secret, but I have no idea what is meant by this sentence.

Does "This is an asymmetrical key" mean that the session keys generated on the server and client are not the same?

Certainly not. The shared secret is the same (it is called shared).

  1. Do bullets 6 and 7 mean that on either the client or the server, the inputs to the algorithm that generates a session key are its own private key, and the other one's public key?

If yes, how are the session keys on the server and client identical, given their inputs are different?

This is the point of the mentioned "mathematical equation". If the colors are not enough explanatory, it is also explanation with numbers on Wikipedia:

  1. Alice and Bob agree to use a modulus p = 23 and base g = 5 (which is a primitive root modulo 23).
  2. Alice chooses a secret integer a = 6, then sends Bob A = ga mod p
    • A = 56 mod 23 = 8
  3. Bob chooses a secret integer b = 15, then sends Alice B = gb mod p
    • B = 515 mod 23 = 19
  4. Alice computes s = Ba mod p
    • s = 196 mod 23 = 2
  5. Bob computes s = Ab mod p
    • s = 815 mod 23 = 2
  6. Alice and Bob now share a secret (the number 2).

The mathematics principle behind this is "multiplicative group of integers modulo p", but similar mechanisms are behind RSA or elliptic curves cryptograpy.

How are the session keys different for different sessions? Are there inputs that are session-specific?

Different session keys are created by different key exchanges, which generate basically random asymmetric key pair on both client and server. It should never happen to you that you would generate the same random random data twice, otherwise it would not be random. Doing that on both client and server eliminates single point of failure (broken random generator), because forcing both server and client to generate the same data is ... pretty impossible.

The input to the key exchange also varies based on the algorithm, but basically there is also randomly chosen modulus (in the above example the number 23). These are three random input parts to the key exchange, that ensures you that will get different shared secret for different sessions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.