2
$\begingroup$

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.

Improve this question
$\endgroup$

2 Answers 2

Reset to default
3
$\begingroup$

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.

Improve this answer
$\endgroup$
5
  • $\begingroup$ 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? $\endgroup$
    – Artem
    Mar 22, 2017 at 19:05
  • $\begingroup$ @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)? $\endgroup$
    – SEJPM
    Mar 22, 2017 at 22:59
  • 1
    $\begingroup$ @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. $\endgroup$
    – Logan
    Mar 23, 2017 at 2:19
  • 1
    $\begingroup$ @SEJPM the server can detect these keys using updated certificate, but the whole problem lies in generation of keys and getting certificate updated. $\endgroup$
    – Logan
    Mar 23, 2017 at 2:47
  • $\begingroup$ 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. $\endgroup$
    – sudo
    Jun 6, 2018 at 22:49
1
$\begingroup$

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.

Improve this answer
$\endgroup$
4
  • $\begingroup$ 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? $\endgroup$
    – Artem
    Mar 22, 2017 at 19:10
  • $\begingroup$ @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. $\endgroup$
    – tylo
    Mar 23, 2017 at 10:59
  • $\begingroup$ 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. $\endgroup$
    – Artem
    Mar 23, 2017 at 11:02
  • $\begingroup$ @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"? $\endgroup$
    – tylo
    Mar 23, 2017 at 11:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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