Writing a replacement for OpenSSH using Go, part 2

Writing a replacement for OpenSSH using Go, part 2(blog.appsdeck.eu)

66 points by _Soulou 11 years ago | 13 comments

0x0 11 years ago |

I'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? :)

Animats 11 years ago | |

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.

Khao 11 years ago | | |

Your second link gives me an error.

bkeroack 11 years ago | |

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.

vertex-four 11 years ago | | |

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.

zzzcpan 11 years ago | |

  > super skeptical about "second-hand" reimplementations

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.

0x0 11 years ago | | |

I 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.

pfortuny 11 years ago |

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.

tptacek 11 years ago | |

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.

pfortuny 11 years ago | | |

Just what I wanted to know. Many thanks, tptacek.