# Challenge Response Authentication - Client Generating Challenge

Let's say we have a client (the not trusted party) and the server(wants to verify that the client is who he claims to be.

The client has access to both the private key and the public key, whereas the server only knows the public key.

Question Instead of the server being responsible for generating the challenge, would it be as safe if the the client himself generated a random challenge and later signed it (so that the server could later verify this). Is there a weakness in RSA that would make this scenario bad?

NOTE The public/private key pair will only be used once, and will be re-generated each time.

The attacker can use replay attack, i.e, he/she can replay a challenge that is signed by the user in the past(which is used as a challenge to server) and can send this as a nonce to the server. To avoid this, server generates and sends the challenge.The idea works if server maintains a list of previous nonce used but this has its limitations on practical implementation.

Hope this helps.

• How about if the public/private key pair will only be used once, and will be re-generated each time? Doesn't this prevent replay attack? – Artem Mar 22 '17 at 19:05
• @Artem how is the server supposed to detect that these keys haven't been used before (ie this is the same problem, you're trusting the other end as a server)? – SEJPM Mar 22 '17 at 22:59
• @Artem the generation of private and public key itself is a big deal in RSA and moreover the generated public key certificate should be updated which is not so easy for CIA. – Logan Mar 23 '17 at 2:19
• @SEJPM the server can detect these keys using updated certificate, but the whole problem lies in generation of keys and getting certificate updated. – Logan Mar 23 '17 at 2:47
• But if the client generates the challenge, couldn't the server keep track of which challenges have already been used so replayed ones can be refused? In either situation, the server has to keep track of that, so it wouldn't be more complicated. – sudo Jun 6 '18 at 22:49

Yes, this defeats the purpose of generating a challenge in the first place.

The main reason to use a challenge-response mechanism is to prevent replay attacks and man-in-the-middle attacks. The server only knows that some signature (or other kind of answer to the challenge) is fresh, if the challenge did not exist previously. If the client generated the challenge, the server would have no control over the challenge and not know when it was actually generated. Especially could an attacker just use the messages from a past authentication to impersonate the client.

Another method for authentication would be one-time passwords. There the server could set up the one-time passwords ahead of time, and then does not have to generate a new challenge each time the client wants to authenticate - he just has to ensure that each password is only used once. But that does require to store some data in both parties. And usually the server would handle the setup of those.

• I've now changed the question with the condition that the public/private key pair changes each time (unique for each challenge-response). Does this change anything? – Artem Mar 22 '17 at 19:10
• @Artem And how can the server actually know the public verification key then? Btw, generating a new key is a lot more effort than just generating a random number in a proper challenge-response mechanism. Anyway, if the key is generated by the client, this still does not guarantee to the server that there is no reply attack or no man-in-the-middle. – tylo Mar 23 '17 at 10:59
• The thing is that everything occurs over SSL, so potentially we could use a password as well. But, I don't want to store any secret on the server, which is why I wanted to use asymmetric cryptography. – Artem Mar 23 '17 at 11:02
• @Artem This sounds like an XY problem: You proposed a solution and not the actual question. Maybe you should open another question with your actual problem / what you want to achieve. As far as I can see, getting rid of the challenge response part does not help you in any way to achieve what you want, tho. If your goal is to store no information about the users at all, then this does not work at all: How should a server distinguish client A saying "Hi, I am client A" and client B saying "Hi, I am client A"? – tylo Mar 23 '17 at 11:58