> 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.
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.