> A number of people are suggesting that this Haskell implementation must be worse than OpenSSL. It probably is. Writing good crypto code is hard. There are probably bugs.
Ok, but if it were vetted as much as openssl, it would probably be much better, yes?
Define "better". Probably it wouldn't be more secure because both would be scrutinized and production-tested about the same. It would protect us against some common C errors but might make us vulnerable to "common" Haskell vulnerabilities. You really can't say.
It probably would be slower though, which is kind of a big deal for webservers and the like.
> It probably would be slower though, which is kind of a big deal for webservers and the like.
More critically, it would only be useful to Haskell code. Haskell, unless C, cannot be embedded. Having a version in Rust - which does not rely on the runtime - ought to be safe from this kind of issue (baring any problem in Rust itself) while being still embeddable from external code. It would still be somewhat slower than C, and of course Rust is far from mature.
The nice thing about this example is that you only need GHC to create the shared library, and then GCC can do the rest with just the .so file produced.
Ok, but if it were vetted as much as openssl, it would probably be much better, yes?