If changing languages lets you reduce code size 20-fold, it's very much worth it.
Reasoning about a smaller code base is nonlinearly easier. This is especially important for security software where letting your reasoning slip usually renders the whole thing useless.
Is that really the case? In Java (my native language, so to say) I quite regularly browse through the language library implementation. I found it quite easy to read and comprehend. I almost always learn something new by doing so.
Not so much for Haskell. When I started with it, I similarly tried to learn by going through the language libraries. Even when I gained some more experience (I am still a beginner and only casual user, though) I have a very hard time to understand what's going on. The code is so dense that I find it hard to understand.
You have an easy time understanding the libraries of your native language, but a hard time understanding the libraries of a language in a completely different paradigm that you're a beginner at? You don't say.
Seriously, the Haskell libraries are understandable and informative - once you learn the language.
That's what I exactly tried to convey: I used that tactic when I was a beginner at Java and hadn't many problems with it. I used the same tactic when Generics came up. I hadn't any problems with it. The beginner can become a better programmer by reading the code. Now I am in a state where I can say: "this shouldn't be implemented that way". Which is completely different and grounds in being Java my native language.
I have casual encounters with Haskell since two years now. Library code is still hard to grok. Don't get me wrong: I like Haskell very much and I am pretty sure that its a decent language to write security critical code in, but I think this is still a problem for many beginners out there. I very rarely stumble on something and say: "hey, that's cool, I will use that in my code". But I admit that I give up after the third nested "lift-<whatever>" ;-).
I want the libraries help me understanding the language, not vice versa. But of course, that's not their primary goal.
When you were a beginner at Java, did you by chance already know how to program in an imperative or OO manner? I find it highly unlikely that anyone unfamiliar with imperative/OO programming in general would get any benefit from reading Java libraries. If you want to get benefit from reading Haskell libraries, just like in Java, you need to learn how to program in the paradigm. Not just "have casual encounters" with it, not just reading things about it, but actually learn the thing.
A direct analogy to what you're saying: When I was studying French, I was able to read articles above my level and get a decently good idea of what they said. Now I'm studying Chinese, and I can't tell at all what characters mean! This should not be surprising. French is very similar to English, where Chinese is very different. Of course picking things up in the latter will be more difficult. It would be absolutely absurd to blame the Chinese language for that.
I think side channel attacks are valid, but in this case they are a red herring. One side channel exploit and what three remote code executions?
It sounds like lots of people (sockpuppet echo chamber) are saying if the new language/runtime doesn't fix all possible flaws we should stay with the broken-on-purpose OpenSSL codebase?
> It sounds like lots of people (sockpuppet echo chamber) are saying if the new language/runtime doesn't fix all possible flaws we should stay with the broken-on-purpose OpenSSL codebase?
I think it's more likely they are saying that replacing one broken implementation with another broken implementation isn't worth the effort.
Sure, remote code execution and reading of arbitrary memory are a lot worse than an attacker figuring out a private key. But if an implementation of a crypto system is not able to conceal the private key, it is completely useless.
Seems to me like we may need to, first of all, redesign some algorithms to be easier to implement in constant time (like Ed25519 and symmetric encryption algorithms that avoid S-boxes), and secondly, develop a language that combines both memory safety and the ability to reason about whether an operation runs in constant time.
I'm not saying this is something we just do, it's a huge undertaking. I'm saying that it seems to me this may be needed, unless we want to find 5 years down the line, when everyone is using a Haskell TLS implementation, that attackers can retrieve the private key through timing attacks. That would be a fairly large effort put towards writing another TLS implementation that is broken by design.
