Not for security
for torturing exploit developers
Encrypting data that goes into server / client would confuse the frick out of most devs and ward off a bunch of them
Not always true, you cant get much info off the player so exploit devs just find it as a game so decrypt it
Sending encrypted stuff doesnt do anything, the player already knows its not sensitive information so why not mess around with it a bit?
Theyll experiment and of course if they get banned they can just make a new account anyway and repeat the process like nothing happened. Once he figures it out you obviously could change a few things but whats the fun in that when theyll just find out the new code in a few days thus resulting in a back and fourth game between the game developer and the exploiter.
you are forgetting the fact that not every exploiter is amazing at coding most would be confused
this onto itself will ward of a lot of exploiter
Update
This is an update of the asset. Please change to latest version: if using require(id)
, no action is required; if using the asset make the corresponding changes.
Changes
- Solved a bug when converting
string
tobytes
.
Changed code:
local function convertType (a) -- LINE 202
--[[local t = type(a)]]
if type(a)--[[t]] == "string" then
local r = {}
for i = 1, string.len(a), 7997 do
table.move(--[[t = ]]{string.byte(a, i--[[ * 7997 - 7996]], i --[[* 7997]]+ 7996)}, 1, 7997, i, r)
--[[for j = 1, #t do
table.insert(r, t[j])
end]]
end
return r
elseif type(a)--[[t]] == "table" then
for _, i in ipairs(a) do
assert(type(i) == "number" and math.floor(i) == i and 0 <= i and i < 256,
"Unable to cast value to bytes")
end
return a
else
error("Unable to cast value to bytes")
end
end
Please comment if you find any bugs or improvements.
Hey, I’ve been waiting for something like this and this looks pretty good.
Did you forget to include a decrypt_CTR
and decrypt_OFB
method, as these are both totally missing from your module and cause the sample code to error stating that the decrypt CTR function doesn’t exist.
If you look at the Information block you will see that some of the encryption modes are Parallelizable which I’m assuming means that the encrypt function can also decrypt the input too.
Sorry for bumping. But this seems like a very good resource! However where’s decrypt_CTR
? Because I have to use CFB as an alternative.
It is merged with encrypt_CTR
function. It’s the same algorithm for both encrypting and decrypting.
I heard CTR encryption was more secure so how would I decrypt CTR encryption as it is an nil value. (Nevermind if you guys have the same problem as me just make decrypt_CTR
in the example code encrypt_CTR
hope this helps you out.)
I had literally the same thought just now.
This resource needs to be known more. Not gonna lie.
Really useful.
not really, they can just use whatever you’re using to decrypt it or just make a decrypter themselves by reading your encryptor script
Seems that link is invalid. Here’s a working link to Parallel Luau.
Additionally, the main difference between coroutines/tasks vs Parallel Luau is that the lua thread created using coroutines/tasks has to wait-in-line for the thread scheduled before it to yield or die; meanwhile, this is all happening on the same OS-thread. Parallel Luau utilizes >1 OS-threads, which balances the load more evenly.
See: Parallel Luau | Roblox Creator Documentation
I’m going to write a wrapper function for this (with authentication and key derivation handled automatically) and see how it goes.
Upcoming update
Well, I quitted the forum… a little bit but I’m back.
So excited to announce that this resource has been rewritten from scratch and the library will suffer a lot of changes:
-
bytes
type will be superseded bybuffer
s which are better for its easy management and performance. - AES library will now contain constructors for a new data type:
AesCipher
which performs better at encrypting and/or decrypting a lot of small and large files and doesn’t run key expansion every time it is needed. - LUTs will be optimized for more direct calculations and also giving some resistance to side-channel attacks.
- Block cipher modes of operation now will have their own space at
Aes.modes
and each of them no longer impact performance. Custom modes can be added as well.
At performance, this library improved the code a lot so it can now process large ammounts of data in a quite short time. Luau Native Code support and Parallel Scripting can be easily ported so it can get even faster than ever! Thus, making this the fastest and most suitable AES library for Roblox.
Some quick tests (ECB mode):
Plaintext size | Encryption av. time | Decryption av. time |
---|---|---|
16 bytes | 0.000037 |
0.000043 |
32 bytes | 0.000054 |
0.000059 |
80 bytes | 0.000095 |
0.000115 |
1600 bytes (1.6 KB) | 0.000981 |
0.001284 |
3200 bytes | 0.002089 |
0.001939 |
160000 bytes (160 KB) | 0.100983 |
0.103678 |
1000000 bytes (1 MB) | 0.586153 |
0.641533 |
5000000 bytes (5 MB) | 2.964735 |
2.918804 |
10000000 bytes (10 MB) | 5.991347 |
5.897557 |
This update will be released when buffers are oficially added to Roblox. Meanwhile I would love to hear some feedback from you. Stay tuned!
Really excited to see this come out!
Do you think you could do test-release for the newer version (if it is complete) so we can give some feedback?
I can send you the preview version via DM.