If this is for serious security, DROP THOSE NOW. Sorry to scream, but the sooner we stop using them, the better.
I also wouldn't spend a lot of time on AES 256, given some of the recently described weaknesses that reduce it to by many bits of strength. Better to work on CAST5, e.g.
Better yet, work on the RNG. Make sure the RNG is cryptographically secure. Without a cryptographically secure RNG, all the key derivation algorithms are pretty much useless.
> Several weak or broken primitives are implemented in this library, for research or legacy reasons. These should not be used under normal circumstances! To restrict their usage, they have been marked as insecure, with the Lockbox.insecure() method. This will cause a failed assertion when you attempt to import the module, unless you set Lockbox.ALLOW_INSECURE to true before the import.
It'd be a little silly to not add AES-256 since I already have AES-128, but I will definitely look into adding CAST5 and CSPRNGs.
I'm excited to pull this into nginx's lua bindings and come up with something cool (and extremely performant)
[1] http://www.lysator.liu.se/~nisse/nettle/ [2] https://github.com/bungle/lua-resty-nettle