

Writing a replacement for OpenSSH using Go, part 2 - _Soulou
http://blog.appsdeck.eu/post/105010314493/writing-a-replacement-to-openssh-using-go-2-2

======
0x0
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
Well, here's the code that Go uses to do elliptic curve encryption:

[https://github.com/golang/crypto/blob/master/curve25519/squa...](https://github.com/golang/crypto/blob/master/curve25519/square_amd64.s)

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...](http://delivery.acm.org/10.1145/2670000/2660370/p299-chen.pdf)

This stuff is really hard to get right.

~~~
Khao
Your second link gives me an error.

~~~
Animats
Here it is without the ACM paywall:

[https://cryptojedi.org/papers/verify25519-20140428.pdf](https://cryptojedi.org/papers/verify25519-20140428.pdf)

------
pfortuny
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
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
Just what I wanted to know. Many thanks, tptacek.

