Hacker News Reader

Comment by pfg | Hacker News Reader

Would you recommend going with Go's crypto/tls if you can get away with it?

If you're using Go, you should use crypto/tls.

What if you're starting a completely new app/lib, and crypto lib quality was more important than language/runtime/ecosystem?

Check if the language/runtime/ecosystem you picked brings a default crypto lib and use that.

Go's C FFI support does exist and there are OpenSSL bindings. But CGo, which will be used in this case, kinda sucks, and you'll have a lot of pain getting the two sides, OpenSSL and the go HTTP lib, to talk properly to eachother.

I think my comment wasn't clear. I am saying, given that I can choose any lang/platform for my new project, and crypto lib quality is the most important, which lang/platform + crypto lib should I choose? Ignoring other factors, what is the best implemented crypto lib out there right now (specifically for TLS or in general)?

For me at least, I chose Go on a recent network project specifically because of the blessed, quality crypto impl for things I needed.

C. It has the widest range of support for crypto libraries, basically any reference implementation of modern crypto algorithms happens in C. Almost all existing libraries are either written in C or support C FFI.

So the most widely supported platform for crypto libs would be C.

But C is probably not a good choice due to other factors outside crypto lib support.

I think the best implemented crypto lib out there atm is NaCl (djb). It has very few functions that take obvious parameters with which you can't blow your leg off (the only danger is repeating a nonce but generating a random nonce or sequential nonce is within the realm of "I expect most people to be able to read /dev/random".)

Second would be any crypto library that is implemented similar: few leg-blow-off-safe functions that do all the hard parts for you.

Reply on news.ycombinator.com