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.
Any updates on when this will be expected to release?
Also, would you be able to add an option for padding?
(Another note: using lua’s and/or is slightly faster than luau’s if/then)
It’s been 7 months, I don’t think there will be one mate
Huge update released
This is an update of the asset. Please change to latest version: huge changes are going to affect old API when using require(id)
.
-
AesCipher
object superseeded old encryption and decryption functions, allowing for more customization, efficiency, organization and developer-friendly environment. -
bytes
pseudo-type doesn’t work anymore, please cast data tostring
s or the modernbuffer
s. - Documentation can be found in the module.
Please comment if you have any issues with this new version.
Nice work. Small correction to the AES.spec script: The last “check” in the “should decrypt properly” section has an Encrypt instead of Decrypt. Would also be nice if you included some examples using different Aes.pads options.
Since it is CTR mode, it would not cause much problems as this mode is symmetric. Thanks for noticing that.
I’m currently looking for that type of documentation.
That is the decision of the user who finds what algorithm is the most suitable for them and the rest is automatic.
I love this, but I’d absolutely love it if i could encrypt strings with it outputting another string instead of a buffer :/.
Its mildly infuriating having to serialize & deserialize my the buffer that it returns.
Yes, it is reasonable. However this library is made like this for preventing unnecessary conversions since it works with buffer
s and is the most effective way to store binary data both for speed and memory.
When encrypting, you usually get some gibberish and converting them to string
s may cause problems related to invalid UTF-8 encoding. That’s why buffer
s make more sense to use in this case.