The next protocol I'm going to talk about is SSH, which is the secure shell protocol.
The problem SSH is trying to solve is also a client server authentication problem.
We have a client who wants to log into the server,
and to log into the server the server asks for the password, and the client enters it.
What we want to know is that when clients are connecting to the server
that they're connecting to the server they think they are
and that an attacker who can intercept and modify this traffic
won't be able to trick the user into giving its password to a different server
or thinking it's interacting with a different server.
This protocol is also based on Diffie-Hellman
and uses aspects of both symmetric and asymmetric cryptography.
The first step is very similar to Diffie-Hellman. In fact, it's the same.
The client picks a large random number and sends to the server g to that power mod p.
G is the generator and p is the modulus just like in Diffie-Hellman.
The server picks its own large random value--we'll call that xs--
and computes ys, which is g raised to that power.
So far this is the same as the Diffie-Hellman protocol.
Then the server computes the key, which is yc--the value transmitted here--
raised to the xs power.
So far this is all the same as what's done in Diffie-Hellman.
We just changed the names of the variables to match the client and server.
The next step is where things get interesting.
What the server will compute is a hash. We'll use some cryptographic has function.
The input to the hash function--first there will be some parameters that identify the protocol.
Those will be concatenated with the public key of the server.
We're assuming at the start of the protocol the server has some public-private key pair.
What will be included in this hash is that public key--public key of the server,
the value of yc that was sent by the client--
that verifies that it's part of the same session and prevents replay attacks,
because now that value was determined by the client,
the value of ys--this is the normal Diffie-Hellman response,
and the key. Note that this is all in a one-way hash.
Someone who intercepts that hash won't be able to learn anything about the inputs.
Someone who knows the inputs would be able to verify that the hash is correct.
So what the server sends is the value of its public key,
the value of ys, and the hash signed with the servers private key.
We finger that as sending the hash along with the hash encrypted with the private key.
That's what it means to do a signature in an asymmetric cryptosystem.
For this quiz, I want to see that you understand the SSH protocol.
At this stage, the client and the server have a shared key.
The question is what should the client do to verify that the server is indeed the server
that the client expects it is talking with.
Check all of the choices that are necessary to verify this.
