# How secure is this?

Hello. I recently discovered a really interesting way to generate a random number. You can take `local clockTime = os.clock()`, then collect all of the numbers to the right of the decimal point by doing `local randomNumber = (clockTime - math.floor(clockTime) - 0.5) * 2 * (range + 1)`. This generates a seemingly random number including, and between negative one, and positive one multiplied by the range to get a range of desired random numbers.

I want to encrypt all of the remote event and remote function traffic between the client and the server. Now the main question / point of this topic is I was wondering how secure would it be to use this method that I mentioned earlier to generate the encryption / decryption keys? How likely is it that a hacker could (somehow) predict what any of the other client / serverâ€™s keys are if they were generated using this method? Iâ€™m not using `tick()` or `os.time()` because the hacker can simply predict those values by calculating what time said client or player has joined the game. But I still have no idea how secure my method is.

Now I know that there is pretty much no reason for me to encrypt the remote event / function traffic between the client and server, there is no use case for this, and no reason for me to do this. But I was simply curious as to how secure this method of generating random numbers is.

Most likely not secure at all depending on how itâ€™s achieved, exploiters are still able to get in.

Iâ€™m not too sure because I donâ€™t create anti exploits but I think that would be really useful, unless someone uses your same method to uncover the encryption key than itâ€™s gonna be safe, and I think that only really skilled exploiters are able to uncover that (unless they uncover it in another easier way, but still)

Gonna be honest, this wouldnâ€™t work. Because of client server desync, the client must always generate the keys, which in this case an exploiter could hook os.clock() to return 0 each time making every encryption key the same. And if the server generates them, then an exploiter could easily hook the RemoteEvent and get the key before itâ€™s even used. And if the key is static, then an exploiter could easily get it by looking in the script environment / gc until they find the key. Thereâ€™s no real way to secure client/server interactions while talking to the client.

2 Likes

I assume this is using the computer clock, if so it would work for the intended method as the clock was started at a diffirent time. The computer clock has its own battery and calculates what time it is. Though this does not mean all clocks are synced. Syncing the clock to another computer is not doable without having both computers.

Note: This is talking about the client generation only, am still unsure if its the actaul clock inside the computer or just the time.

How could this happen? The hacker only has control of their computer, they canâ€™t just control how the keys are generated on the other clients? Or somehow they can? I would understand them being able to hook `os.clock()` on their own client, but I have no idea how they could do it to other computers.

What Iâ€™m planning to do is a Diffie Hellman key exchange. I will generate private keys on the server, and client. These private keys will never be sent or revealed to anybody. Ever. The only thing that will be sent to the client is the serverâ€™s public key, and the only thing sent to the server will be the clientâ€™s public key.

and

I donâ€™t know how the value of `os.clock()` is determined. But according to itâ€™s documentation, itâ€™s supposed to be the CPU time or something like that. Iâ€™m using all of the numbers to the right of the decimal point to calculate the random number (Which will be a number between zero and one).

What Iâ€™m planning to do is a Diffie Hellman key exchange. I will generate private keys on the server, and client. And public keys on the client and servers. None of these keys have to be exactly the same, so this shouldnâ€™t be much of an issue. (Unless I donâ€™t understand how a Diffie Hellman key exchange works)

Itâ€™s impossible for exploiters to get into the server, and they canâ€™t get into other playerâ€™s computers. Unless there is some type of backdoor.

If you read my post, I talked about how I would achieve this.

1 Like

For what itâ€™s worth, you can just use modular division for that:
`os.clock()%1`

As far as security though, systems like this only secure the system against manually firing remote events. But there are a dozen different ways to automate remote event traffic, and a lot of it doesnâ€™t even need to be from inside of Roblox. They can use external software to do whatever needs to be done.

3 Likes

basing your encryption around what time it currently is will be broken very quickly.

Based on your first post, you probably know but for anyone looking at this thread: key exchange doesnâ€™t prevent hackers from sending what ever data they want, it will only protect their data from man-in-the-middle attacks where someone else is reading the packets between your hacker and the server. Diffie Hellman is not an anti-exploit

Itâ€™s not secure at all. Any exploiter who reads the client code will be able to dissect which section of your code generates the key and fire remotes freely.

For example, letâ€™s say this is a LocalScript in your game.

``````local key = GetEncryptionKey()

remote:FireServer(key, data)
``````

Just by quickly reading your code, I can already see how you are generating these encryption keys, even if on the remote logger they look â€śrandomâ€ť, the code still shows me how theyâ€™re done.

I could then just write an exploit like

``````local key = GetEncryptionKey()

remote:FireServer(key, maliciousData)
``````

Even if the client code is encrypted, exploiters could still find a way to dissect the code and find which part generates the encryption key. Anything on the client is completely vulnerable and all the checks must be performed on the server.

You asked how secure it would be, not how to achieve it. Also generating keys and passing it from client to server is still not safe, due to exploiters just being able to get the keys from looking at the argâ€™s passed though

Exactly. This is how I would achieve it:

Ignore the fact that I even talked about encryption. My main question / the whole point of the topic was too see if hackers could predict the value of `os.clock()` on other playerâ€™s computers.

I would understand if they would be able to predict the value of `os.time()` or `tick()` on other playerâ€™s computers, because these are seconds since the January 1st, 1970 epoch. But I donâ€™t see how they could predict / figure out what the value of `os.clock()` is on other playerâ€™s computer because if I remember correctly this value has almost nothing to do with the amount of seconds since some date. But this is why I made the topic, to see if they could. Hackers canâ€™t break into other players computers to fetch this value either.

More

Also, if I remember correctly. Diffie Hellman key exchange completely mitigates this problem, because the only thing you are sending are the public keys. And these are meant to be sent, and itâ€™s ok if hackers know what the value of the public keys are, because you canâ€™t somehow calculate what the private keys are using the public keys. Itâ€™s the private keys that are also generated that donâ€™t get sent.