Same email as the previous one with the links fixed, sorry for the
On Sun, Aug 13, 2017, at 02:15, Xazo -Tak wrote:
> I'm guessing that box.lua (and what it requires) is the asymmetric encryption algorithm, but where is the documentation?
> It uses an unusual set of jargon, doesn't say how it should be used, and doesn't say anything about itself.
> From what I can gather, it's hardcoded to generate 256 bit keys; so unless this blows RSA out of the water in terms of efficiency, it's either going to be too insecure to protect the small amount of sensitive data or too slow to protect the large amount of less-sensitive data.
It's elliptic curves, the short key lengths are an advantage over RSA
This is a straightforward port of the same API from NaCL, see  and
It is compatible with it, and you can check that it gives the same
results as the C code (besides the private key generation, everything is
This scheme has been designed by D.J. Bernstein and is generally
admitted to be good, but don't take my word for it...
The main issue IMO is generating good random bytes in pure Lua. After
discussing it with the author of PLC I just sent a pull request  that
removes key generation from the API, only exposing a function to deduce
a public key from a private key. You are expected to provide a private
key yourself, it should be 32 bytes with the best entropy possible.
I know it lacks documentation, we are not entirely sure on the final API
we want yet. Like I said for now I just copied the tweetnacl API.
But yeah, it's a 1 day old crypto code in a dynamic language, I wouldn't
trust it beyond what's reasonable. The disclaimer at the bottom of the
PLC readme applies .
org/doc/public-key_ cryptography/authenticated_ encryption.html