Hello there! So recently I have been experimenting with “encrypting” strings with Roblox Luau, keyed stuff.
One of the ideas I have came across was keyed XOR, something (to my knowledge) what Adonis uses to secure their remotes if I recall correctly.
Example:
function xor(a, b)
local result = 0
local bitval = 1
while a > 0 or b > 0 do
local abit = a % 2
local bbit = b % 2
if abit ~= bbit then
result = result + bitval
end
bitval = bitval * 2
a = math.floor(a / 2)
b = math.floor(b / 2)
end
return result
end
function xor_string(str: string, key: string)
local result = {}
for i = 1, #str do
local byte1 = str:byte(i)
local byte2 = key:byte((i - 1) % #key + 1)
table.insert(result, string.char(xor(byte1, byte2)))
end
return table.concat(result)
end
Though, I came to the conclusion that keyed XOR has a wack ton of security issues (let alone from time to time improperly unencoding incorrect ascii chars) after some experimentation with it. And I was wondering if there would be any other methods that could be used that are both more secure and less prone to errors.
xor is very well defined. If you’re encoding something and it’s decoding wrong, then your implementation is wrong. You can also use the built in bit32.bxor instead of implementing it manually.
With that said, the choice of encryption will depend on your use case, and most algorithms will be relatively more complex than xor to make for better “security”. As for sending stuff over remotes, you probably just want to use a super simple cipher like xor which is just fast. The reason you wouldn’t want to overdo it is that the client can just inspect the code anyway, so you don’t gain any more benefit and instead just slow down your code.
I must agree that more complex algorithms would eat more resources to unencrypt or encrypt thus causing the code to slow down, but for experimentation sake over practicality, what would realistically be more secure than XOR or other relatively simpler ciphers that gets used, and something that is not as overkill such as AES?
In practice things tend to either be secure or not depending on the available attacks, with AES with enough bits being considered secure by modern standards. If you just want something simpler, maybe Twofish (secure) or Triple DES (not secure) could be fun to implement.
Lets say you have two people, Lets name both of them Point A and Point B. And Point A wants to get a message to Point B, but if A was to give the message directly to B, then anyone in the middle would be able to read this message, or even edit it and give it to B, and B would assume its A giving them the message.
Or in another case, where A wishes to give B instructions. Anyone in the middle who is not A would be able to freely give B any kind of instruction and B will carry it out assuming its coming from A (man in the middle attack).
Now with encryption, we scramble our message into an humanly unreadable string, and then pass that string over to B, which B decodes it into a readable message, while anyone in the middle is unable to read what A is saying to B, like a secret language only A and B knows.
Now this is only a simple explanation and does not go into detail on how encryption works.
Now one of the most highly used use cases in Roblox of string encryption is normally when you’d want to let the client give data to the server through Remotes, or any other unsecure networking method.
Anyone with Remote Spy allows the client to listen to these remotes and see the data/messages being sent throughout these remotes. And in lots of cases, copy the data, edit it, and then retransmit it through that same remote to abuse it (example: a gun system local script asking the server sided gun system to damage a player who the server presumes is getting shot at by user, but in reality a exploiter is firing this remote to kill them without actually shooting at them).
In most cases normally the developer would add a bunch of sanity checks in between these requests to check if they are legitimate or not, which is really good practice, BUT they can be bypassed or sometimes even trigger false positives if not properly implemented.
That’s why some developers opts to encrypt the data going in between the client and server, and server to client, which is both easier and much faster to do. But also has its own issues if also not properly implemented, such as Key storage.
Some developers stores keys (which are used to tell the decryption system/function how to decode the data) on the client, which really defeats the purpose of even using encryption in the first place, since an exploiter can easily view local script contents with systems like Dex.
I know some other developers gets the client to request a key from the server and then save it in memory, which is more secure than storing it directly hard coding it on the client, but I’m unsure how secure this practice is, so I won’t go into it.
I’m guessing that the way this works is by making the message the local script is sending unreadable, and hackers trying to edit the local script message won’t be able to edit it because they can’t understand what the script is doing, but the server script will get the message and reassemble it back to an actual message and be able to carry on knowing that it’s the local script that send it not some third party (hackers) who edit it, am I right?
also i have a question, what situation would you need to use it, is it like for all local scripts or just local script that are attached to server scripts which can edit the outcome of the server
