Cryptography support through the scripting interface

[Armored-Dragon]

"They said we couldn't do it. They said we shouldn't do it. They begged us not to do it, and we did it anyway!" - Soldier

This provides basic cryptography support through the scripting interface utilizing OpenSSL.

Currently, errors generated using these interfaces will simply return a null value. For example, if a encryption fails, instead of receiving a string containing the encrypted data, you will receive null.

The function names are not finalized just yet. I need to come up with some easy to use and understand names for the future. I am also working on how to include key pair generation options when trying to generate a new key pair. There are different padding methods available to us. The current default is to use what are the recommended options, but having alternatives might make sense seeing as how other padding methods are still somewhat used.

The current outputs of this interface will always be PEM formatted. This interface also always assumes PEM formatted keys as an input.

TODO:

• AES encryption
• Replace function names
• Support alternative methods of RSA padding (probably makes more sense than having smaller key size support?)

[Armored-Dragon]

Do we want to still support 512 bit length RSA keys. 512 bit length keys are laughably insecure these days, and OpenSSL is currently discussing whether to disable key generation using 512 bit lengths. Several other projects have also removed key generation support of lower than 1024 bits already.
I ask because until the trigger is pulled from OpenSSL to actually remove 512 bit length generation, the ball is in our court. If we want to support this, I will need to provide special handing of this key length in some situations such as encrypting messages. From what I can find, due to my use of OAEP padding, encrypting anything using a 512 bit length key is impossible.

I will probably be removing it unless there is any real reason to keep it. I doubt there are any legacy applications here that would require such a thing.

[ada-tv]

Should encryptRSA and decryptRSA handle QByteArrays that can be passed into Script.btoa in the script, rather than passing base64 QStrings?

Enc/decrypting binary data would be handy to have as well