Scenario Challenge-Response (asymmetric)

You can also carry out challenge-response method with an asymmetric encryption method. So great exertion to secure exchange for every client server pair can be avoided.

Categorical there are two alternatives, but furthermore only the first will be treated:

  1. For authentication the server sends a Challenge (random number) to the client, who signs it with his secret key and then sends the result back to the server. Now everyone, knowing the client´s public key, so as well the server, can verify the Response, viz verify that the challenge was signed by the use of the client´s private key, which only he owns.

  2. For authentication the server sends a Challenge to the client, consisting of a random number encrypted by the use of the client´s public key. The client decrypts the challenge by the use of his private key and returns the result (the random number) to the server. Now the server can verify if the received random numbers equals the sent one. Do they match, the server can be sure it was sent from the client, because only he has the private key to decrypt the challenge. Thus, that alternative expects true random numbers, to prevent an attackers guess the response. Because of that the first alternative is preferred in most cases.

Your task as attacker is, again, to find acceptance by Server 1 as Client. This time there is a very special solution. If you fail to find one you can get one here.

To Solution