4 ms·
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 G
by 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