crypt.decrypt/crypt.encrypt needs further standardization

[jdpatdiscord]

A current point of contention for scripters - especially ones with special needs for whitelisting - definitely suffer from lack of standardization on this front.

UNC declares it as crypt.decrypt(data: string, key: string, IV: string?): string,
Synapse as: syn.crypt.decrypt(data: string, key: string): string, and
Script-Ware as: crypt.decrypt(data: string, key: string, iv: string, mode: string) despite existing documentation saying otherwise.

Synapse makes the standard algorithm AES-GCM, Script-Ware claims to be AES-CTR - I was unable to find documentation for Krnl, Fluxus, and Oxygen U to confirm theirs.

Some AES implementations hold the random IV in the text returned in order to reduce it to one payload instead of requiring two sets of data in order to function, but other forms do not.

[jdpatdiscord]

In addition, certain AES algorithms are more open to attacks than others. This also needs to be looked into and then standardized according to the most secure and/or performant algorithm.

[zzerexx]

Krnl, Fluxus, and Oxygen U do not have any encryption or decryption functions.
They only offer Base64 encoding/decoding and hashing with SHA-384.