4 ms·

To incompletely quote Rob Pike: "If crypto is so hard that only one implementation is allowed to exist, it's crypto that needs to be rethought" https://groups.

To incompletely quote Rob Pike: "If crypto is so hard that only one implementation is allowed to exist, it's crypto that needs to be rethought" https://groups.google.com/d/msg/golang-nuts/0za-R3wVaeQ/M8_BiuaZ_2YJ https://groups.google.com/d/msg/golang-nuts/0za-R3wVaeQ/M8_B... Why do crypto people only want there to be a single C implementation of everything?

16s 13y ago
Amen. All these people who parrot, "Don't roll you own crypto" need to get out of the math/programming kitchen and go get a crypto burger from some national fast food joint. My advice would be don't roll your own primitives, but other than that, have at it.
Ygg2 13y ago
Apparently yes, Rust also asked crypto people about rolling their own crypto. And their answer was - "Don't." Crypto is just so mind boggling hard from what I gather, there are probably hunderds of ways attacker can mess up the system. But overall I agree - there shouldn't be a single implementation of anything ever. Crypto people need to come up with some kind of test or prover, or something that can tell programs if they are safe enough, and where they aren't. A kind of test harness or program prover.
- rlpb 13y ago
  > A kind of test harness or program prover. I suppose they need to solve the halting problem, too?
  - Ygg2 13y ago
    Well something that deals with basic problems first. I don't think having a way to test for timing attacks is too far out. I guess you should aim for good enough and not perfect.
- gnuvince 13y ago
  They can only test for flaws that they can think of.
  - Ygg2 13y ago
    That would be enough for starters. A dedicated enough enemy will bypass your defenses sooner or later.
- jerf 13y ago
  "Crypto is just so mind boggling hard from what I gather, there are probably hunderds of ways attacker can mess up the system." One of the problems that is really hard to get around is the "timing attack"; by passing various values into a crypto system and seeing how long it takes to either return or error out, you can learn things, often entirely decoding a message in surprisingly short amounts of time. To defend against this, a crypto system must make pervasive use of operations that take the same amount of time whether they succeed or fail. For instance, if you are comparing one string against another, you must compare the same amount of string regardless of the input; you can't bail out at the first difference, which is what you would normally do. Unfortunately, as hardware gets more and more complicated this gets harder and harder to guarantee. Surprisingly small differences have been demonstrated to crack messages. And the worst part is, this is all advantage attacker; the attacker does not need to know why he's seeing timing differences, he can just figure out what they mean and exploit them. It's the defender that has to figure out (for example) that some predictive algorithm on the CPU sometimes preloads the next chunk of RAM and sometimes doesn't according to the alignment that your buffer happened to receive, depending on the (attacker-controlled) size of the first packet, and then figure out what to do about it. The upshot of this is that crypto implemented in darned near anything other than assembler is probably flawed. C is the standard because that just isn't practical, but almost anything higher than C is dangerous. Many of the things that a high-level language consider a feature make programming proper industrial-strength crypto either difficult, or simply impossible. (Good luck preventing timing attacks in Haskell. The language and runtime fights you with every fiber of its being. And the ways in which it is fighting you are good thing the vast majority of the time... just not this one.) It's relatively easy to produce a crypto library that emits the correct streams and decodes the incoming streams into the proper values, but that is merely the beginning of creating a truly robust crypto library; it's not even the halfway point. It's the easy part. Go's crypto is built by people who know this stuff, so for instance: http://golang.org/pkg/crypto/subtle/ http://golang.org/pkg/crypto/subtle/ However, they do not claim it has been vetted by anybody in particular. Proving their implementation correct is very difficult, and I'd still worry about whether GC is going to bite somebody somehow in the implementation, nor is there any particular proof that they didn't miss a place they should use one of those functions, and I wouldn't bet my life the functions are 100% correct in all cases, either. (They're simple, they look good, but one stray compiler optimization and.... who knows?)
rmc 13y ago
Why do crypto people only want there to be a single C implementation of everything? Because it's hard, and if you make a mistake, it means there is no security.
lmm 13y ago
Most languages, go included, are hopelessly unsuited for writing crypto code, which cares about precise processor behavior in a way that no other problem does. Honestly I suspect with the current state of C compiler optimizations the only language suitable for writing crypto primitives is assembler.
- sacado2 13y ago
  Or just turn off compiler optimizations.
pjmlp 13y ago
> Why do crypto people only want there to be a single C implementation of everything? It doesn't need to be a C implementation, but crypto is very very easy to get wrong. So never try a new implementation if you don't fully understand existing ones.
mwsherman 13y ago
A crypto monoculture seems dangerous, too. A single implementation sounds naively attractive but it also represents a single point of failure. I’d rather have many imperfect-and-actively-improving implementations, than a single implementation that is widely relied upon and fails.

16s 13y ago

Amen. All these people who parrot, "Don't roll you own crypto" need to get out of the math/programming kitchen and go get a crypto burger from some national fast food joint. My advice would be don't roll your own primitives, but other than that, have at it.

Ygg2 13y ago

Apparently yes, Rust also asked crypto people about rolling their own crypto. And their answer was - "Don't." Crypto is just so mind boggling hard from what I gather, there are probably hunderds of ways attacker can mess up the system. But overall I agree - there shouldn't be a single implementation of anything ever. Crypto people need to come up with some kind of test or prover, or something that can tell programs if they are safe enough, and where they aren't. A kind of test harness or program prover.

rlpb 13y ago
> A kind of test harness or program prover. I suppose they need to solve the halting problem, too?
- Ygg2 13y ago
  Well something that deals with basic problems first. I don't think having a way to test for timing attacks is too far out. I guess you should aim for good enough and not perfect.
gnuvince 13y ago
They can only test for flaws that they can think of.
- Ygg2 13y ago
  That would be enough for starters. A dedicated enough enemy will bypass your defenses sooner or later.
jerf 13y ago
"Crypto is just so mind boggling hard from what I gather, there are probably hunderds of ways attacker can mess up the system." One of the problems that is really hard to get around is the "timing attack"; by passing various values into a crypto system and seeing how long it takes to either return or error out, you can learn things, often entirely decoding a message in surprisingly short amounts of time. To defend against this, a crypto system must make pervasive use of operations that take the same amount of time whether they succeed or fail. For instance, if you are comparing one string against another, you must compare the same amount of string regardless of the input; you can't bail out at the first difference, which is what you would normally do. Unfortunately, as hardware gets more and more complicated this gets harder and harder to guarantee. Surprisingly small differences have been demonstrated to crack messages. And the worst part is, this is all advantage attacker; the attacker does not need to know why he's seeing timing differences, he can just figure out what they mean and exploit them. It's the defender that has to figure out (for example) that some predictive algorithm on the CPU sometimes preloads the next chunk of RAM and sometimes doesn't according to the alignment that your buffer happened to receive, depending on the (attacker-controlled) size of the first packet, and then figure out what to do about it. The upshot of this is that crypto implemented in darned near anything other than assembler is probably flawed. C is the standard because that just isn't practical, but almost anything higher than C is dangerous. Many of the things that a high-level language consider a feature make programming proper industrial-strength crypto either difficult, or simply impossible. (Good luck preventing timing attacks in Haskell. The language and runtime fights you with every fiber of its being. And the ways in which it is fighting you are good thing the vast majority of the time... just not this one.) It's relatively easy to produce a crypto library that emits the correct streams and decodes the incoming streams into the proper values, but that is merely the beginning of creating a truly robust crypto library; it's not even the halfway point. It's the easy part. Go's crypto is built by people who know this stuff, so for instance: http://golang.org/pkg/crypto/subtle/ http://golang.org/pkg/crypto/subtle/ However, they do not claim it has been vetted by anybody in particular. Proving their implementation correct is very difficult, and I'd still worry about whether GC is going to bite somebody somehow in the implementation, nor is there any particular proof that they didn't miss a place they should use one of those functions, and I wouldn't bet my life the functions are 100% correct in all cases, either. (They're simple, they look good, but one stray compiler optimization and.... who knows?)

rmc 13y ago

Why do crypto people only want there to be a single C implementation of everything? Because it's hard, and if you make a mistake, it means there is no security.

lmm 13y ago

Most languages, go included, are hopelessly unsuited for writing crypto code, which cares about precise processor behavior in a way that no other problem does. Honestly I suspect with the current state of C compiler optimizations the only language suitable for writing crypto primitives is assembler.

sacado2 13y ago
Or just turn off compiler optimizations.

pjmlp 13y ago

> Why do crypto people only want there to be a single C implementation of everything? It doesn't need to be a C implementation, but crypto is very very easy to get wrong. So never try a new implementation if you don't fully understand existing ones.

mwsherman 13y ago

A crypto monoculture seems dangerous, too. A single implementation sounds naively attractive but it also represents a single point of failure. I’d rather have many imperfect-and-actively-improving implementations, than a single implementation that is widely relied upon and fails.