Show HN: The Lua Lockbox
github.com
Show HN: The Lua Lockbox
1–8 of 8 posts
Re: Show HN: The Lua Lockbox
#2This is very useful - thanks! I've got a project that I could use this in - so I'll be spending this week getting familiar with this codebase .. see you on github!
Re: Show HN: The Lua Lockbox
#3That is some very clean-written Lua. Kudos!
I'm excited to pull this into nginx's lua bindings and come up with something cool (and extremely performant)
Re: Show HN: The Lua Lockbox
#4This is definitely a nice reference implementation of crypto algorithms in pure Lua, but please, please do not use it for production encryption.
Anything written in an interpreted (or worse, JIT-ted) language will be almost definitely vulnerable to timing attacks. Lua already has bindings to C/C++ crypto libraries if you need to encrypt or create MACs.
Re: Show HN: The Lua Lockbox
#5Interesting idea. But I question the overall security philosophy of a project that includes so many suspected to be weak, known to be weak, or provably weak algorithms, e.g., MD2, MD4, MD5, SHA-1, and DES.
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.
Re: Show HN: The Lua Lockbox
#6Interesting idea. But I question the overall security philosophy of a project that includes so many suspected to be weak, known to be weak, or provably weak algorithms, e.g., MD2, MD4, MD5, SHA-1, and DES. 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…
I agree! There are quite a few provably insecure algorithms in the project. That said, I do think they are useful to keep around: As a reference, for legacy systems, or to practice cracking.
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.
Re: Show HN: The Lua Lockbox
#7Interesting idea. But I question the overall security philosophy of a project that includes so many suspected to be weak, known to be weak, or provably weak algorithms, e.g., MD2, MD4, MD5, SHA-1, and DES. 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…
Per the README, it appears these are disabled by default:
> 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.
Re: Show HN: The Lua Lockbox
#8That is some very clean-written Lua. Kudos! I'm excited to pull this into nginx's lua bindings and come up with something cool (and extremely performant)
Nginx Lua bindings does have direct access to OpenSSL primitives (or LibreSSL, or BoringSSL). I have also created (LuaJIT) binding to libnettle [1] that you can find from here [2]. (libhogweed, aka rsa/dsa bindings, and documentation are still a work in progress).
[1] http://www.lysator.liu.se/~nisse/nettle/ [2] https://github.com/bungle/lua-resty-nettle