But I'd like your opinion and advice on it before I submit a pull request.
Because I don't wont to force anyone to include all of the above algorithms in their application at the moment only hash functions for which crypto.RegisterHash from the Go stdlib has been called are included.
But there are two problems with this approach:
for one after calling crypto.RegisterHash typically by something like import _ "crypto/sha256" you need to call ReloadCryptoAlgorithms for the functions to be added to the module and
you can't yet add any non Go stdlib hash functions
The second could be solved by the registerHash function which just needed to be exported. The same is with registerBlockCipher which accepts a generic block cipher and adds functions for all block modes and registerCipherFuncs which adds en- and decryption functions for generic ciphers.
I can think of three solutions:
Exporting these functions which could clutter the interface of github.com/d5/tengo/stdlib
Hardcoding a set of algorithms which I would not recommend
Creating a subpackage github.com/d5/tengo/stdlib/crypto which contains a constructor with the algorithms as parameters. In BuiltinModules there would be just an instance with maybe AES, the SHAs and SHA3s.
I personally would prefer the third option because it doesn't clutter the github.com/d5/tengo/stdlib package but still contains all features. And people embedding tengo in non security critical applications won't need to decide which algorithms to make available.
I have written a crypto module which exports functions for encrypting and decrypting AES in CBC, CTR, OFB and GCM mode,
lots of hash functions
MD4 MD5 SHA1 SHA224 SHA256 SHA384 SHA512 MD5SHA1 RIPEMD160 SHA3_224 SHA3_256 SHA3_384 SHA3_512 SHA512_224 SHA512_256 BLAKE2s_256 BLAKE2b_256 BLAKE2b_384 BLAKE2b_512
But I'd like your opinion and advice on it before I submit a pull request.
Because I don't wont to force anyone to include all of the above algorithms in their application at the moment only hash functions for which
crypto.RegisterHashfrom the Go stdlib has been called are included. But there are two problems with this approach:crypto.RegisterHashtypically by something likeimport _ "crypto/sha256"you need to callReloadCryptoAlgorithmsfor the functions to be added to the module andThe second could be solved by the
registerHashfunction which just needed to be exported. The same is withregisterBlockCipherwhich accepts a generic block cipher and adds functions for all block modes andregisterCipherFuncswhich adds en- and decryption functions for generic ciphers.I can think of three solutions:
github.com/d5/tengo/stdlibgithub.com/d5/tengo/stdlib/cryptowhich contains a constructor with the algorithms as parameters. InBuiltinModulesthere would be just an instance with maybe AES, the SHAs and SHA3s.I personally would prefer the third option because it doesn't clutter the
github.com/d5/tengo/stdlibpackage but still contains all features. And people embedding tengo in non security critical applications won't need to decide which algorithms to make available.