
Pure Go implementation of the NaCL set of APIs - kevinburke
https://github.com/kevinburke/nacl?hn
======
inglor
I love the README, it's very modest and I enjoy reading things like "if a
function is longer than, say, 5 lines, I didn't write it myself." and "While
you probably shouldn't trust random security code from the Internet, I'm
reasonably confident that this code is secure. I did not implement any of the
hard math (poly1305, XSalsa20, curve25519) myself - I call into
golang.org/x/crypto for all of those functions. I also ported over every test
I could find from the C/C++ code, and associated RFC's, and ensured that these
libraries passed those tests."

I will wait for other companies to use it first - but it looks like a very
level-headed implementation that won't be hard for the author to maintain -
and a very useful tool.

------
wvh
Thanks! I've been wondering why the golang crypto repo contains only half an
implementation for so long. I guess people are not generally eager to take
responsibility for crypto implementations, especially semi-official ones...

It would be nice if the golang devs would pick an Argon2 implementation too
(Blake2 hash is already there); it always feels prudent not to use any crypto
libraries lest they receive some sort of semi-official blessing from the
either language's own creators or renowned cryptographers.

------
staticassertion
Did a quick ctrl + F in the readme to look for how they handle timing attacks
in Go. As this is a pure Go implementation, I'm curious - how are these
attacks mitigated, or is that left to consumers of the library?

~~~
inglor
Some of these attacks are mitigated through the underlying golang crypto
package [https://golang.org/pkg/crypto/](https://golang.org/pkg/crypto/) \-
you can see what's constant time and what you have to handle yourself to deal
with timing attacks in
[https://github.com/golang/go/commit/850e55b8c028440f2fe28285...](https://github.com/golang/go/commit/850e55b8c028440f2fe282858b332cb810a06864)

The library (as a wrapper) doesn't do anything with regards to timing attacks.

~~~
staticassertion
Nothing seems to state that it _isn 't_ vulnerable to timing attacks.
Everything seems to be. That's unsurprising, since it's all pure go.

~~~
inglor
I'll clarify - it _is_ vulnerable to timing attacks (except where explicitly
mentioned otherwise) - and you should take care of that in your code.

It is pretty trivial to defend from timing attacks in a language like go (just
race a goroutine with a delay). I agree that it's a good point to bring up
though.

~~~
staticassertion
Seems like something that should be mentioned in the README. Users of this
library, by default, are vulnerable.

I'm not sold on the 'race a goroutine' solution either, but I'm not much of a
Go programmer.

~~~
0xdeadbeefbabe
Do you want a situation where the guy who reads the whole README shouldn't use
the library?

------
geoah
Amazing work, thank you! Let's see if saltpack[1] will move to this at some
point! :D

1\. [https://github.com/keybase/saltpack](https://github.com/keybase/saltpack)

------
Asooka
I'm confused - does this have anything to do with Google's NaCL plug-in
architecture for Chrome? Or is it only a set of crypto routines that have an
unfortunate name collision with the former?

~~~
tracker1
I had that thought as well... wasn't sure if it was meant to present an NaCL
capable runtime.. then the readme pretty much cleared it up. Naming things is
hard.

------
justinsaccount
Also interesting, this is the first package I've seen in the wild that uses
Bazel.

~~~
moderation
Sort of expected being a Google project but Istio [1] is being built using
Envoy. Google is involved but Envoy [2] is owned by Lyft and is also using
Bazel.

1\.
[https://github.com/istio/istio/blob/master/devel/README.md#s...](https://github.com/istio/istio/blob/master/devel/README.md#setting-
up-bazel) 2\.
[https://github.com/lyft/envoy/blob/master/DEVELOPER.md](https://github.com/lyft/envoy/blob/master/DEVELOPER.md)

~~~
kevinburke
for the record - this is not a Google project, I'm not a Google employee. I
just put the Go license on it because I borrowed some of the code and didn't
want to deal with the hassle of relicensing etc.

I'm interested in Bazel because of the speed/caching parts, and because Go
might be headed in that direction soon.

~~~
justinsaccount
Neat.. For go I haven't really thought about using it, but I've been working
on a project that uses a bunch of bleeding edge C libs.

Building the project involves building 3 repos from different git branches
before building my little C program. Literally just

git clone && checkout && ./autogen.sh && ./configure && make install

3 times.

I'd love if I could just make a BUILD file for bazel and be able to just have
$MAGIC happen. Especially since it looks like the bazel c target has
'linkstatic' for building a static binary.

~~~
kevinburke
it's getting there... see the Travis CI config for getting bazel for this repo
specifically, or,
[https://github.com/bazelbuild/rules_go](https://github.com/bazelbuild/rules_go)
has go-specific instructions

------
donpark
Excellent. I am using my own pure-go lib, hacked up just to avoid hassle of
binding to native code, but it supports only features I need.

Thanks Kevin.

------
0xdeadbeefbabe
Oh good. I was just about to use [https://github.com/GoKillers/libsodium-
go](https://github.com/GoKillers/libsodium-go), but I'd rather not have to
depend on CGO.

