[0x01]

If we accept that C is here to stay for the time being, but is difficult to manage memory, then why don't we use a mid-way solution?

Lua is built on c, and is much more (than C) memory safe. It retains all the advantages of C (ie, can go anywhere), and we limit the C to 17.3k (as of 5.2.3) lines of c, which is relatively static (won't change, won't bloat in the same way maintaining/building on current C SSL implementations), and could allow us to handle memory safely.

I'm curious why this approach is not used. Portability? Proficiency? Lua is quite possibly the most beautiful language to read. I can't see any downsides, but I'll gladly be enlightened!

[masklinn]

Well for a start lua not having integers would be an issue when implementing cryptographic primitives. The second issue is while lua is relatively lightweight, carrying a full lua runtime for each of the libraries you're using would still get unwieldy and costly, adding ~400K to each embedder according to the About page ("Under 64-bit Linux, […] the Lua library takes 414K")

[0x01]

Apologies. I should have referenced Lua 5.3 instead as it has both integer and bitwise operator support. This should satisfy the concerns regarding crypto implementation.

As for the space considerations, I have two ways to reason this:

* Wouldn't it only take up 1x414K? If you create luaSSL as a drop in replacement to OpenSSL, you'd only need one copy in your filesystem, just as you only have one OpenSSL.

* Even if you bloat your binary sizes by 414K per executable, isn't it worth it to go from "yes, it could be unsafe, we'll never know... let's wait for the next CVE" to 100% guaranteed no memory faults EVER? Nothing is free, and this could be a cheap price to pay for the guarantee of memory safety, and the implications that come with it.

Edit: wording

[acveilleux]

For crypto-primitives, you usually want them to be constant-time. This is basically impossible to do in an interpreter or a JIT, indeed optimizing compilers can and will optimize contant-time operations out so inline assembly is commonly used.

[0x01]

Thank you for the info!

[Sir_Cmpwn]

Speed and ease of using low level techniques, probably.