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?
Because it's hard, and if you make a mistake, it means there is no security.
My advice would be don't roll your own primitives, but other than that, have at it.
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.
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.
I suppose they need to solve the halting problem, too?
I guess you should aim for good enough and not perfect.
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/ 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?)
I’d rather have many imperfect-and-actively-improving implementations, than a single implementation that is widely relied upon and fails.