from Hacker News

Writing a replacement for OpenSSH using Go, part 2

by _Soulou on 12/12/14, 6:10 PM with 13 comments

• by 0x0 on 12/12/14, 7:26 PM

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

• by pfortuny on 12/12/14, 7:35 PM

  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.