4 ms·

I think the OpenSSL binding are really only necessary if you follow the train of though that, "its new so it must be broken". I prefer tests and evidence and I

I think the OpenSSL binding are really only necessary if you follow the train of though that, "its new so it must be broken". I prefer tests and evidence and I would not hesitate to use the Go cypto in many production scenarios. To distrust something with no evidence of being broken seems like magical thinking to me. Go 1.1 includes a better map implementation, so if they were starting now that probably would not have been needed. Most large systems always end up performing some customization to standard logging solutions as well.

tptacek 14y ago
The Go developer he's citing is probably Adam Langley, who is responsible for a good chunk of pkg/crypto and is also Chrome's TLS security person. I started with Go some months back and ran into a compat issue with their SSL library almost immediately (it couldn't handle Firefox's goofy SSL compat dance in proxy mode). Assuming that any new crypto implementation was safe sounds like magical thinking to me.
- voidlogic 14y ago
  I would agree that OpenSSL is safer than using Go crypto. But I haven't seen any compelling evidence that it is any less secure than other non-Open SSL solutions. Like anything else, find a bug, report it/fix it.
  - tptacek 14y ago
    That's because you're not looking for evidence. Just look at Langley's Twitter feed: Golang's SSL still has Lucky13 timing channels, and the RSA and elliptic/ECDSA code hasn't been assessed for side channels. I like Go, a lot, but I think you should hold off on recommending crypto libraries ("I wouldn't hesitate to use this library in production"); that's something you want to be sure about before you develop opinions.
    - voidlogic 14y ago
      To be clear I said I thought the Go crypo was suitable for some production uses. The text you put it quotes was not anything I ever said. I would rather use OpenSSL for a banking app for example. Since Go is >= version 1.0 and the crypo libraries in the standard library and not in go/exp, etc Go is implicitly endorsing them for some production use. I found closed issues that might be the ones you mentioned. If you are aware of issues, you should file them: http://code.google.com/p/go/issues/list?can=2&q=crypto&colspec=ID+Status+Stars+Priority+Owner+Reporter+Summary&cells=tiles http://code.google.com/p/go/issues/list?can=2&q=crypto&#...
      - wglb 14y ago
        The text you put it quotes was not anything I ever said Pretty close: He said "I wouldn't hesitate to use this library in production". You actually said "I would not hesitate to use the Go cypto in many production scenarios."

tptacek 14y ago

The Go developer he's citing is probably Adam Langley, who is responsible for a good chunk of pkg/crypto and is also Chrome's TLS security person. I started with Go some months back and ran into a compat issue with their SSL library almost immediately (it couldn't handle Firefox's goofy SSL compat dance in proxy mode). Assuming that any new crypto implementation was safe sounds like magical thinking to me.

voidlogic 14y ago
I would agree that OpenSSL is safer than using Go crypto. But I haven't seen any compelling evidence that it is any less secure than other non-Open SSL solutions. Like anything else, find a bug, report it/fix it.
- tptacek 14y ago
  That's because you're not looking for evidence. Just look at Langley's Twitter feed: Golang's SSL still has Lucky13 timing channels, and the RSA and elliptic/ECDSA code hasn't been assessed for side channels. I like Go, a lot, but I think you should hold off on recommending crypto libraries ("I wouldn't hesitate to use this library in production"); that's something you want to be sure about before you develop opinions.
  - voidlogic 14y ago
    To be clear I said I thought the Go crypo was suitable for some production uses. The text you put it quotes was not anything I ever said. I would rather use OpenSSL for a banking app for example. Since Go is >= version 1.0 and the crypo libraries in the standard library and not in go/exp, etc Go is implicitly endorsing them for some production use. I found closed issues that might be the ones you mentioned. If you are aware of issues, you should file them: http://code.google.com/p/go/issues/list?can=2&q=crypto&colspec=ID+Status+Stars+Priority+Owner+Reporter+Summary&cells=tiles http://code.google.com/p/go/issues/list?can=2&q=crypto&#...
    - wglb 14y ago
      The text you put it quotes was not anything I ever said Pretty close: He said "I wouldn't hesitate to use this library in production". You actually said "I would not hesitate to use the Go cypto in many production scenarios."