3 ms·
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
by 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 agoI 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 agoYes, 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