Writing a replacement for OpenSSH using Go, part 2
blog.appsdeck.euI'm always super skeptical about "second-hand" reimplementations of crypto protocols like these, because after working through a few of the crypto challenges around, it's pretty obvious that it is very easy to end up with vulnerable code.
Compared to a lot of other code, where you can easily tell you're "done" because "it works", with crypto code you're only halfways there. Not only does it have to work, but it has to not break and not leak secrets, too. Anything from timing attacks to bad handling of padding, bad random generators, not to speak of buffer overflows and logic errors (goto fail, anyone?)
I'm thinking it would be prudent to at least use separate keys for anything interfacing with non-default implementations. Can't remember the details but wasn't there an issue where if any (gpg? ssl?) key had been used for signing on a certain flawed implementation, its secrets were spilled?
What's the state of the Go SSH library, has it been vetted by ... veterans? :)
Well, here's the code that Go uses to do elliptic curve encryption:
https://github.com/golang/crypto/blob/master/curve25519/squa...
It's in assembler, with no comments. It's from Bernstein's code, via Supercop, and is not original to the Go team.
A recent effort to formally verify that code, out of Taiwan, Japan, and the Netherlands, found one bug not previously detected by testing.
http://delivery.acm.org/10.1145/2670000/2660370/p299-chen.pd...
This stuff is really hard to get right.
Your second link gives me an error.
Here it is without the ACM paywall:
I agree that it's hard to get right. On the other hand we should be careful not to completely discourage new crypto tools from being developed. Yes they have to be very carefully written, tested and verified, but let's not perpetuate the myth that only a small cabal of experts are allowed to write crypto software.
On the other hand, anyone who does write crypto software must be able to keep up with the research in the field of crypto. Things can't just be tested and verified once - it's a process of constantly testing and verifying against new attacks. You cannot prove that anything is unbreakable, only that it's not subject to known attacks.
The reality is that most developers are not going to be able to spend significant amounts of time paying attention to the research and figuring out how it applies to their code - after all, in most cases, your users don't understand security, and you'll have the constant pressure to add features to your application instead, and honestly, security just isn't that fun for most people that they'd want to spend all their time on it.
I can't help but think that the OpenSSL situation would not be so bad if more hackers were encouraged to participate in crypto libs. Even if nobody understands it at first, just going through the source will end up creating more crypto authorities in the community who can fix bugs and create new tools. As opposed to the forbidden black art that crypto is today.
Horseshit. Anyone can learn cryptography, and anyone (just look at the history of the code) can add code to OpenSSL. The problem is that the parent commenter is correct, and that writing serious crypto code takes a serious research commitment. Nobody wants to do that; they just want to get the "crypto" hooked up to the "web chat" as quickly as they can.
It is frankly exhausting hearing the repetitive drone of people who couldn't exploit a CBC padding oracle if their life depended on it complaining about how crypto is a secret cabal.
I'm just curious, how first-hand implementations are different? Obviously they could end up with vulnerable code just as easily and there's a ton of evidence they do.> super skeptical about "second-hand" reimplementationsI guess what I meant was the type of libraries that (often non-crypto-experts) port over to their favorite language. I'm sure that Go is one of the better ones, but there's lots of "random" implementations of ssh/ssl/crypto floating around on sourceforge/codeplex/pear/github/whatever which are unlikely to have been as thoroughly battle-tested as the ubiquitous ones.
Any references about the security of cryptographic primitives in Go? I mean: side-channel attacks, timing attacks and the behaviour of rand().
Because that is the first thing I would look into.
Thanks.
I am just asking (a bit fearful, yes), not simply ranting.
The ones in the standard library are implemented for the most part by subject matter experts and are probably more trustworthy than OpenSSL's, which is what virtually everything else uses.
Just what I wanted to know. Many thanks, tptacek.