5 ms·

The response to a subtle weakness in cryptographic software should not be to reimplement the cryptographic implementation from scratch. This inevitably introduc

The response to a subtle weakness in cryptographic software should not be to reimplement the cryptographic implementation from scratch. This inevitably introduces far more problems than it solves.

thisisdave 13y ago
I don't think this is a response to a recently-disclosed weakness in OpenSSL. The project has been active for almost four years. Minor edit: almost four years
chongli 13y ago
This inevitably introduces far more problems than it solves. Could you elaborate more on this? I fail to see how this is inevitable.
thinkpad20 13y ago
You're not wrong, but this clearly wasn't written overnight in respond to the news. There are almost a thousand commits in this repo.
betterunix 13y ago
Heartbleed is not exactly a "subtle weakness," it is a gaping hole -- and it is a gaping hole that is only possible in languages with simple pointers and simple pointer arithmetic. In other words, using better languages for the next generation of crypto implementations will prevent this from happening, and then we can all get back to worrying about subtle weaknesses.
amalcon 13y ago
Haskell is a particularly odd choice for a project like this, as lazy evaluation makes it difficult to reason about the runtime of various operations under various conditions. Something with a bit more ML in its blood would be better, and for a library that pretty much means OCaml. Edit: I do not at all mean to imply that it is impossible to implement TLS securely in Haskell. Only that there are more natural choices if one wants the advantage of a strong algebraic type system.
- quasque 13y ago
  Could you elaborate on how lazy evaluation is problematic for such a project?
  - chongli 13y ago
    Nope. This is a common troll whenever any Haskell project is mentioned. It's despicable FUD and just plain wrong. Haskell makes it very easy and lightweight to add strictness annotations to your data structures; far, far easier than it is to add laziness to a strict-by-default language.
  - bvttf 13y ago
    Not him, but I don't think the regular lazy evaluation worry about building up a million thunks and GC hell would be as much of a problem as it being awkward to not have things happen too fast and leave side channel attacks from timing.
  - amalcon 13y ago
    In cryptography, for most operations, you need to be sure that the operation takes the same amount of time for all possible inputs. Otherwise, you leak information. The classic example of this is checking string equality with strncmp(): this takes a different amount of time depending on how similar the strings are. If one string is secret and the other is controlled by an attacker, the attacker can use a clock and multiple attempts to discover the secret. Obviously this particular one isn't relevant to SSL, but there are a number of other possibilities to worry about in most languages, most obviously short-circuiting operations like boolean AND/OR. Lazy evaluation makes every operation short-circuit, so you need to worry about this in every operation. It can be done, but it's harder than it needs to be.
    - automatthew 13y ago
      So we should choose the approach that gives us trivial attacks that reveal 64K straight out of Compton to the approach that may be slightly harder to defend against timing attacks?
PeterisP 13y ago
I'd rather say that the long list of overflow-related vulnerabilities would be a good argument to ensure that all crypto libraries are implemented in some kind of a strict language that disallows a large class of vulnerabilities, even if it costs us some time and effort. Seriously, for many languages bugs cause unintended behavior within bounds of implemented logic - such as the recent logic bug that returned an 'okay' response even if the certificate was invalid; however, the fact that ordinary bugs tend to have effects of "read arbitrary memory" or "execute arbitrary code" is a very specific niche of C and friends. In a language appropriate for security, a bug in heartbeat extension would break the heartbeat extension - maybe disable heartbeats not work, maybe cause different heartbeats - but it should be unable to affect the rest of application. In a language appropriate for security, if a single module is secure (i.e., the limited number of API/method calls it exposes are secure), then bugs in all other modules shouldn't be able to affect the insides of that module; so if your app has a tiny core that does some signing w/o exposing the key secrets, then the rest of the app can't touch it even deliberately, much less by an acidental bug.

The response to a subtle weakness in cryptographic software should not be to reimplement the cryptographic implementation from scratch. This inevitably introduces far more problems than it solves.

thisisdave 13y ago

I don't think this is a response to a recently-disclosed weakness in OpenSSL. The project has been active for almost four years. Minor edit: almost four years

chongli 13y ago

This inevitably introduces far more problems than it solves. Could you elaborate more on this? I fail to see how this is inevitable.

thinkpad20 13y ago

You're not wrong, but this clearly wasn't written overnight in respond to the news. There are almost a thousand commits in this repo.

betterunix 13y ago

Heartbleed is not exactly a "subtle weakness," it is a gaping hole -- and it is a gaping hole that is only possible in languages with simple pointers and simple pointer arithmetic. In other words, using better languages for the next generation of crypto implementations will prevent this from happening, and then we can all get back to worrying about subtle weaknesses.

amalcon 13y ago

Haskell is a particularly odd choice for a project like this, as lazy evaluation makes it difficult to reason about the runtime of various operations under various conditions. Something with a bit more ML in its blood would be better, and for a library that pretty much means OCaml. Edit: I do not at all mean to imply that it is impossible to implement TLS securely in Haskell. Only that there are more natural choices if one wants the advantage of a strong algebraic type system.

quasque 13y ago
Could you elaborate on how lazy evaluation is problematic for such a project?
- chongli 13y ago
  Nope. This is a common troll whenever any Haskell project is mentioned. It's despicable FUD and just plain wrong. Haskell makes it very easy and lightweight to add strictness annotations to your data structures; far, far easier than it is to add laziness to a strict-by-default language.
- bvttf 13y ago
  Not him, but I don't think the regular lazy evaluation worry about building up a million thunks and GC hell would be as much of a problem as it being awkward to not have things happen too fast and leave side channel attacks from timing.
- amalcon 13y ago
  In cryptography, for most operations, you need to be sure that the operation takes the same amount of time for all possible inputs. Otherwise, you leak information. The classic example of this is checking string equality with strncmp(): this takes a different amount of time depending on how similar the strings are. If one string is secret and the other is controlled by an attacker, the attacker can use a clock and multiple attempts to discover the secret. Obviously this particular one isn't relevant to SSL, but there are a number of other possibilities to worry about in most languages, most obviously short-circuiting operations like boolean AND/OR. Lazy evaluation makes every operation short-circuit, so you need to worry about this in every operation. It can be done, but it's harder than it needs to be.
  - automatthew 13y ago
    So we should choose the approach that gives us trivial attacks that reveal 64K straight out of Compton to the approach that may be slightly harder to defend against timing attacks?

PeterisP 13y ago

I'd rather say that the long list of overflow-related vulnerabilities would be a good argument to ensure that all crypto libraries are implemented in some kind of a strict language that disallows a large class of vulnerabilities, even if it costs us some time and effort. Seriously, for many languages bugs cause unintended behavior within bounds of implemented logic - such as the recent logic bug that returned an 'okay' response even if the certificate was invalid; however, the fact that ordinary bugs tend to have effects of "read arbitrary memory" or "execute arbitrary code" is a very specific niche of C and friends. In a language appropriate for security, a bug in heartbeat extension would break the heartbeat extension - maybe disable heartbeats not work, maybe cause different heartbeats - but it should be unable to affect the rest of application. In a language appropriate for security, if a single module is secure (i.e., the limited number of API/method calls it exposes are secure), then bugs in all other modules shouldn't be able to affect the insides of that module; so if your app has a tiny core that does some signing w/o exposing the key secrets, then the rest of the app can't touch it even deliberately, much less by an acidental bug.