0

Many remote-terminal to server authentication protocols use random numbers sent by the server as a challenge that the user will encrypt and send back to the server. This way an adversary cannot perform a replay attack since the number being encrypted and sent to the server (along with other parameters) is random and unknown beforehand.

But what if the adversary always records the line and maps each random number he/she ever encountered to the encrypted traffic coming after it ?

If the adversary meets a random number previously sent by the server he/she will be able to replay the traffic.

So why not use timestamp as a challenge ? A timestamp always grows and will always be different than any previous timestamp ?

Why is the use of random numbers preferable to timestamps ?

Edit: Let's say the client and server share the same password (user's password) so encrypting a future timestamp would be impossible for the replay attacker without knowing the user's password.

  • i dont understand your question.Are you asking why time stamp is not used instead of random numbers or Are you talking about breaking SSL? – Vipul Nair Jun 25 at 16:37
  • "But what if the adversary always records the line and maps each random number he/she ever encountered to the encrypted traffic coming after it ?"what does this line mean? – Vipul Nair Jun 25 at 16:38
0

This white paper from ExploitDB will likely answer many of your questions.

https://www.exploit-db.com/docs/english/41621-attacking-rdp---how-to-eavesdrop-on-poorly-secured-rdp-connections.pdf

My best guess is they chose to use a pseudo random number because they choose to use a XOR operation, which requires the key to be at least the same length as the plaintext for efficacy. Because a timestamp would always be fixed length, it eliminates a good deal of key possibilities.

Disclaimer: I'm not a cryptanalyst, and this question may be better suited to the Cryptography StackExchange Community.

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.