1

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 '19 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 '19 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.

0

Thinking about this from a cryptographic stand point, there are multiple information stages we are concerned about. The clear text, the cypher text, and the keys to decrypt and encrypt that’s data. In a public key algorithm, anyone can identify the public key and the cypher text. The security lies in concealing the clear text and the encryption key to ensure an attacker cannot do anything of value if they were to intercept the messages. This is one of the principles behind future secured cryptography.

If you were to use a timestamp, the clear text challenge is much easier to determine. The lack of randomness gives an attacker three of the four parts of information that hep keep encrypted data secure. This makes the job of a cracker that much easier to identify what the encrypted messages are or even what they will be. Therefor, it is better to risk an accidental collision through a randomly generated key than to create a guessable challenge.

In your example of the day encrypted timestamp, you’re encrypting the time stamp with a symmetric key, but the underlying data is still a timestamp. As a developer, consider that an attacker may have access to your code and algorithms. Your user password plays no role in the encryption of communicated traffic and could be discarded. This level of attack is why it’s difficult to home generate a new cryptographic algorithm. Your code must be able to sit in an attackers hands (just for reading) and still withstand attack.

0

If the underlying crypto system is solid, it does not really matter if you use a timestamp, a counter, or a random number. If the backend is well written, the key cannot be determined even if the attacker knows the public key, the cyphertext AND the cleartext.

If your backend uses AES, this is not you should care about. An attacker will not be able to generate anything useful nor deduce the private key.

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