Pure Go implementation of the NaCL set of APIs | Hacker News Reader

Pure Go implementation of the NaCL set of APIs

github.com

108 pointskevinburke19 comments

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.

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.

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?

Some of these attacks are mitigated through the underlying golang crypto package 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...

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

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.

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.

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.

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

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

1. https://github.com/keybase/saltpack

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?

the latter: https://nacl.cr.yp.to/

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.

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

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... 2. https://github.com/lyft/envoy/blob/master/DEVELOPER.md

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.

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.

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

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.

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

Reply on news.ycombinator.com