3 ms·

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

by pfg 9y ago

tptacek 9y ago
If you're using Go, you should use crypto/tls.
- kodablah 9y ago
  What if you're starting a completely new app/lib, and crypto lib quality was more important than language/runtime/ecosystem?
  - zaarn 9y ago
    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.
    - kodablah 9y ago
      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.
      - zaarn 9y ago
        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.

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

by pfg 9y ago

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

tptacek 9y ago

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

kodablah 9y ago
What if you're starting a completely new app/lib, and crypto lib quality was more important than language/runtime/ecosystem?
- zaarn 9y ago
  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.
  - kodablah 9y ago
    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.
    - zaarn 9y ago
      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.