3 ms·

So I can't tell easily (mea culpa, I'm new to Go) but were the crypto speedups also timing-attack-safe?

by drewcoo 14y ago

laurent123456 14y ago
Shouldn't that be a property of the algorithm rather than the implementation? I mean as long as they implement the algorithm correctly, do they need to care about being timing-attack-safe?
- pbsd 14y ago
  Yes and no. Certain algorithms make it harder to do timing-resistant implementations, but by no means impossible. Probably the easiest mistake to make is on DH/RSA exponentiation. Using the simple square-and-multiply algorithm gives away plenty of timing data; you usually need to explicitly protect against it by either using blinding or always performing both the square and multiply at each iteration.
- arnehormann 14y ago
  Yes, they do. Read http://www.imperialviolet.org/2013/02/04/luckythirteen.html http://www.imperialviolet.org/2013/02/04/luckythirteen.html - even a division in the cpu may introduce timing differences depending on the input (bottom of the blog post). https://groups.google.com/forum/?fromgroups=#!topic/golang-nuts/HF5O5vAKRcQ https://groups.google.com/forum/?fromgroups=#!topic/golang-n... indicates golangs implentation may not be timing attack safe, but that's another version and I don't know for sure.
_ak 14y ago
Can't speak about the speedups per se, but since the standard library has a package with certain operations necessary in crypto implementations to preempt timing attacks, I would say they know what they're doing: http://golang.org/pkg/crypto/subtle/ http://golang.org/pkg/crypto/subtle/
dchest 14y ago
agl (https://news.ycombinator.com/user?id=agl https://news.ycombinator.com/user?id=agl) knows better, as he wrote most crypto in Go, but here's what I know. AES and RC4 in Go standard library are not constant time. AES should be timing safe when used on amd64 CPU with AES instructions. RSA is blinded, but not constant time, and ECC is not constant time (amd64 implementation of curve25519 in go.crypto is constant time, though). The linked hash functions (MD5 and SHA1) shouldn't be used for cryptography, but they and SHA-2 should be safe as there are no loads or branches that depend on secret data. If you want a timing safe cipher, use (X)Salsa20 from go.crypto repository.

So I can't tell easily (mea culpa, I'm new to Go) but were the crypto speedups also timing-attack-safe?

by drewcoo 14y ago

So I can't tell easily (mea culpa, I'm new to Go) but were the crypto speedups also timing-attack-safe?

Shouldn't that be a property of the algorithm rather than the implementation? I mean as long as they implement the algorithm correctly, do they need to care about being timing-attack-safe?

pbsd 14y ago
Yes and no. Certain algorithms make it harder to do timing-resistant implementations, but by no means impossible. Probably the easiest mistake to make is on DH/RSA exponentiation. Using the simple square-and-multiply algorithm gives away plenty of timing data; you usually need to explicitly protect against it by either using blinding or always performing both the square and multiply at each iteration.
arnehormann 14y ago
Yes, they do. Read http://www.imperialviolet.org/2013/02/04/luckythirteen.html http://www.imperialviolet.org/2013/02/04/luckythirteen.html - even a division in the cpu may introduce timing differences depending on the input (bottom of the blog post). https://groups.google.com/forum/?fromgroups=#!topic/golang-nuts/HF5O5vAKRcQ https://groups.google.com/forum/?fromgroups=#!topic/golang-n... indicates golangs implentation may not be timing attack safe, but that's another version and I don't know for sure.

_ak 14y ago

Can't speak about the speedups per se, but since the standard library has a package with certain operations necessary in crypto implementations to preempt timing attacks, I would say they know what they're doing: http://golang.org/pkg/crypto/subtle/ http://golang.org/pkg/crypto/subtle/

dchest 14y ago

agl (https://news.ycombinator.com/user?id=agl https://news.ycombinator.com/user?id=agl) knows better, as he wrote most crypto in Go, but here's what I know. AES and RC4 in Go standard library are not constant time. AES should be timing safe when used on amd64 CPU with AES instructions. RSA is blinded, but not constant time, and ECC is not constant time (amd64 implementation of curve25519 in go.crypto is constant time, though). The linked hash functions (MD5 and SHA1) shouldn't be used for cryptography, but they and SHA-2 should be safe as there are no loads or branches that depend on secret data. If you want a timing safe cipher, use (X)Salsa20 from go.crypto repository.