I never worked with modules and seeing a question on how to do AES encoding/decoding in GatewayScript I thought this is a great sample for learning about modules and easily make use of libraries found on the internet.
With the first release (188.8.131.52) GatewayScript will be available there will be no crypto library support.
(This is similar to XQuery/JSONiq new with version 184.108.40.206 having no access to dp:variables and HTTP header, that came with 220.127.116.11 firmware)
A word of caution here:
It is always better to use Encrypt/Decrypt/Sig/Verify actions instead of DataPower crypto extension functions in XSLT.
Reason is that the actions are hardened against Oracle Padding attacks -- using crypto extension functions YOU are responsible.
Anyway, since 18.104.22.168 GatewayScript does not ship any crypto funcitons, using self written or found libraries is your only current option.
Doing "View Page Source" I saw that these 4 code parts were included into the page:
utf8.js / base64.js / aes.js / aes-ctr.js
You get them unmodified if you do "Save Page as" as "complete webpage".
So I decided to make 4 modules out of them, store under "local:" on DataPower and just require("aes-ctr") in order to use it. To make functionality available from the module the last line "module.exports = ...;" had to be appended to each file. And in order to use functionality eg. from module "utf8" var Utf8 = require("utf8"); had to be added at the top of the modules.
Here you can see demonstration GatewayScript aes.demo.js in action:
$ coproc2 aes.demo.js ../ab.json http://dp6-l3:2227Password: L0ck it up saf3Plaintext: pssst ... đon’t tell anyøne!Encrypted ...: GQK5heUZjVNxqjSRRj0HzMJwPrW+OMWOaL5RXzzvfklqdViJraQ8tQ==... Decrypted: pssst ... đon’t tell anyøne!128-bit: 69 c4 e0 d8 6a 7b 04 30 d8 cd b7 80 70 b4 c5 5a192-bit: dd a9 7c a4 86 4c df e0 6e af 70 a0 ec 0d 71 91256-bit: 8e a2 b7 ca 51 67 45 bf ea fc 49 90 4b 49 60 89$$ coproc2 aes.demo.js ../ab.json http://dp6-l3:2227Password: L0ck it up saf3Plaintext: pssst ... đon’t tell anyøne!Encrypted ...: RQFLXOcZjVNuGspYI20khzUJKbmeb6WOFBSL/cQPfX+1pnr+pmQP+Q==... Decrypted: pssst ... đon’t tell anyøne!128-bit: 69 c4 e0 d8 6a 7b 04 30 d8 cd b7 80 70 b4 c5 5a192-bit: dd a9 7c a4 86 4c df e0 6e af 70 a0 ec 0d 71 91256-bit: 8e a2 b7 ca 51 67 45 bf ea fc 49 90 4b 49 60 89$
The output for the three test vectors from Appendix C of NIST AES spec should be
- 128-bit: 69 c4 e0 d8 6a 7b 04 30 d8 cd b7 80 70 b4 c5 5a
- 192-bit: dd a9 7c a4 86 4c df e0 6e af 70 a0 ec 0d 71 91
- 256-bit: 8e a2 b7 ca 51 67 45 bf ea fc 49 90 4b 49 60 89
Now we have seen that aes.demo.js works fine, here is it completely:
The little helper function "_()" at the bottom of aes.demo.js was only intended to be a nice oneline implementation of "byte array to hex string" conversion.
To my total surprise it seems to outperform other implementations by orders(!) of magnitude!?!?! I verified that on jsperf.com, try it out yourself (I hope the test result is "real"):
(at least it produces the needed hexadecimal output for the NIST test vectors above)
Vyacheslav Egorov pointed out that the measurements were flawed: