Let's please write the replacement in a language that has some built-in safety guarantees, and ideally some features supporting correctness proofs.
Haskell comes to mind. If we want to avoid a runtime, let's go for a language like Rust, which also has strong safety guarantees and lots of Haskell/ML-inspired features that help improve both safety and readability (advanced pattern matching, Options, immutability guarantees, etc.)
Both of these languages are sufficiently fast to develop high-performance crypto frameworks, and both have good FFIs for calling optimized C code if necessary.
Isn't there a significant tension between the performance impact of using cryptography more widely and the efficiency of the implementations? Let's suppose that implementing low level libraries is 50% or 200% or 500% less efficient than implementing them in C. Now consider that there are good reasons to use these libraries more widely.
Can those memory safe languages be called by other languages? Or moving that library to another language will force python/ruby/etc. to rewrite (a large) part of their own FFI?
Comments
Let's please write the replacement in a language that has some built-in safety guarantees, and ideally some features supporting correctness proofs.
Haskell comes to mind. If we want to avoid a runtime, let's go for a language like Rust, which also has strong safety guarantees and lots of Haskell/ML-inspired features that help improve both safety and readability (advanced pattern matching, Options, immutability guarantees, etc.)
Both of these languages are sufficiently fast to develop high-performance crypto frameworks, and both have good FFIs for calling optimized C code if necessary.
Isn't there a significant tension between the performance impact of using cryptography more widely and the efficiency of the implementations? Let's suppose that implementing low level libraries is 50% or 200% or 500% less efficient than implementing them in C. Now consider that there are good reasons to use these libraries more widely.
Can those memory safe languages be called by other languages? Or moving that library to another language will force python/ruby/etc. to rewrite (a large) part of their own FFI?