3 ms·

> pure Go AES => slower, but safer Just curious, why Go AES is safer than OpenSSL or GnuTLS, anyone? Or safer here means something other than secure?

4ad 12y ago
Because Go is a memory-safe language (unlike C), therefore a large class of bugs that have plagued OpenSSL are avoided. That being said, the AES implementation uses fast assembly code, if possible, so some safety is lost. In any case, TLS would have provided a better example, AES is much easier to audit for correctness than TLS.
- drdaeman 12y ago
  I don't really understand crypto, but I suspect while adding memory safety high level primitives without any guarantees about their low-level behavior could lead to various side-channel attacks. When implementing AES some had to resort to SIMD assembly instructions[1] instead of plain C to avoid timing attacks. [1]: http://crypto.stanford.edu/vpaes/ http://crypto.stanford.edu/vpaes/
  - 4ad 12y ago
    Yes, and the Go implementation takes all this into consideration (whether it does a good enough job is not decided yet). The timing behaviour of the compiled Go code is very well understood, and it is (or can be made) very similar to the behaviour for C. When this is not enough, assembly is used. Please see http://golang.org/pkg/crypto/subtle http://golang.org/pkg/crypto/subtle.
    - drdaeman 12y ago
      > all this It certainly does, but is it really all of this? For example, I had read that AES has a timing attack[1] due to non-constant time array access due to CPU caches being significantly faster that RAM. I don't see `ConstantTimeArrayAccess` there. And when you have to fall back to assembly (like Go does for x86_64[2]), grandparent posts' argument for high-level languages as a less error prone is getting weaker (although it still stands true, as attack surface is shallower) [1]: http://cr.yp.to/antiforgery/cachetiming-20050414.pdf http://cr.yp.to/antiforgery/cachetiming-20050414.pdf [2]: http://golang.org/src/pkg/crypto/aes/asm_amd64.s http://golang.org/src/pkg/crypto/aes/asm_amd64.s
SwellJoe 12y ago
Several classes of security problem, including the Heartbleed bug, are impossible or very unlikely in a language that doesn't have manual memory management. His assertion is theoretical...he assumes a Go implementation will be superior based on this removal of a huge class of potential problems. But, it is difficult to be certain without an audit and a lot of real world testing and experience with the library. It is not unreasonable, however, to assume that security libraries in a language like Go could be safer than similar libraries in a language with manual memory management like C/C++. Purely functional programming and programming without side effects (as in Haskell) can also reduce some types of error and make for more provably correct software, but Go is not particularly pure in this regard...but, as I understand it, can be used in a manner that is similar in many ways. Again, this could prevent entire classes of common security problem.
- diminish 12y ago
  Thanks for nice explanation. My crypto class teacher on coursera (Dan Boneh of Stanford) used to repeat one thing again and again; "Don't design or implement crypto systems yourself". His argument was that crypto required the validation of time and a lot of experts (working as adversaries). From this point of view, a young language or implementation seems to be at a disadvantage compared to older ones. Of course fresh memories of Hearbleed seems to contradict what I say. But what doesn't kill OpenSSL makes it stronger or (get forked).

4ad 12y ago

Because Go is a memory-safe language (unlike C), therefore a large class of bugs that have plagued OpenSSL are avoided. That being said, the AES implementation uses fast assembly code, if possible, so some safety is lost. In any case, TLS would have provided a better example, AES is much easier to audit for correctness than TLS.

drdaeman 12y ago
I don't really understand crypto, but I suspect while adding memory safety high level primitives without any guarantees about their low-level behavior could lead to various side-channel attacks. When implementing AES some had to resort to SIMD assembly instructions[1] instead of plain C to avoid timing attacks. [1]: http://crypto.stanford.edu/vpaes/ http://crypto.stanford.edu/vpaes/
- 4ad 12y ago
  Yes, and the Go implementation takes all this into consideration (whether it does a good enough job is not decided yet). The timing behaviour of the compiled Go code is very well understood, and it is (or can be made) very similar to the behaviour for C. When this is not enough, assembly is used. Please see http://golang.org/pkg/crypto/subtle http://golang.org/pkg/crypto/subtle.
  - drdaeman 12y ago
    > all this It certainly does, but is it really all of this? For example, I had read that AES has a timing attack[1] due to non-constant time array access due to CPU caches being significantly faster that RAM. I don't see `ConstantTimeArrayAccess` there. And when you have to fall back to assembly (like Go does for x86_64[2]), grandparent posts' argument for high-level languages as a less error prone is getting weaker (although it still stands true, as attack surface is shallower) [1]: http://cr.yp.to/antiforgery/cachetiming-20050414.pdf http://cr.yp.to/antiforgery/cachetiming-20050414.pdf [2]: http://golang.org/src/pkg/crypto/aes/asm_amd64.s http://golang.org/src/pkg/crypto/aes/asm_amd64.s

SwellJoe 12y ago

Several classes of security problem, including the Heartbleed bug, are impossible or very unlikely in a language that doesn't have manual memory management. His assertion is theoretical...he assumes a Go implementation will be superior based on this removal of a huge class of potential problems. But, it is difficult to be certain without an audit and a lot of real world testing and experience with the library. It is not unreasonable, however, to assume that security libraries in a language like Go could be safer than similar libraries in a language with manual memory management like C/C++. Purely functional programming and programming without side effects (as in Haskell) can also reduce some types of error and make for more provably correct software, but Go is not particularly pure in this regard...but, as I understand it, can be used in a manner that is similar in many ways. Again, this could prevent entire classes of common security problem.

diminish 12y ago
Thanks for nice explanation. My crypto class teacher on coursera (Dan Boneh of Stanford) used to repeat one thing again and again; "Don't design or implement crypto systems yourself". His argument was that crypto required the validation of time and a lot of experts (working as adversaries). From this point of view, a young language or implementation seems to be at a disadvantage compared to older ones. Of course fresh memories of Hearbleed seems to contradict what I say. But what doesn't kill OpenSSL makes it stronger or (get forked).