3 ms·

Not this one: http://eprint.iacr.org/2014/161.pdf http://eprint.iacr.org/2014/161.pdf

by runeks 13y ago

sitkack 13y ago
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?
- runeks 13y ago
  > 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.
  - sitkack 13y ago
    How huge? So huge we should stay on OpenSSL! Here are all the current TLS implementations http://en.wikipedia.org/wiki/Comparison_of_TLS_implementations http://en.wikipedia.org/wiki/Comparison_of_TLS_implementatio... There is room for one in a secure language. Completely useless? Go ahead and throw the baby out with the bathwater. At this point OpenSSL is a net negative. It really smells like you are spreading FUD to keep people on OpenSSL.

Not this one: http://eprint.iacr.org/2014/161.pdf http://eprint.iacr.org/2014/161.pdf

by runeks 13y ago

Not this one: http://eprint.iacr.org/2014/161.pdf http://eprint.iacr.org/2014/161.pdf

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?

runeks 13y ago
> 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.
- sitkack 13y ago
  How huge? So huge we should stay on OpenSSL! Here are all the current TLS implementations http://en.wikipedia.org/wiki/Comparison_of_TLS_implementations http://en.wikipedia.org/wiki/Comparison_of_TLS_implementatio... There is room for one in a secure language. Completely useless? Go ahead and throw the baby out with the bathwater. At this point OpenSSL is a net negative. It really smells like you are spreading FUD to keep people on OpenSSL.