4 ms·
I was actually at this talk (excellent way to go over this kind of topic!) and I have just a small thing to add. You'll notice the "Asymmetric Signature" secti
by Etzos 10y ago
I was actually at this talk (excellent way to go over this kind of topic!) and I have just a small thing to add.
You'll notice the "Asymmetric Signature" section mentions using ESDSA on P-256 because "the Go implementation of
P-256 is constant time to protect against side-channel attacks." However, someone mentioned that this may not be on all platforms because it is hand-coded assembly. After a quick check of the Go source code, this is indeed true. In fact, the constant time guarantee assembly version is only available on amd64 compatible systems[1]. Just something to take note of.
[1] https://golang.org/src/crypto/elliptic/ https://golang.org/src/crypto/elliptic/
Edit: Formatting and grammar and spelling, oh my.
- gtank 10y agoAuthor here, glad you enjoyed the talk! Looking into it more I noticed that there's a Go implementation[1] that is noted to be constant-time with a !amd64 build tag. So it isn't just the assembly one. [1] https://golang.org/src/crypto/elliptic/p256.go https://golang.org/src/crypto/elliptic/p256.go
- Etzos 10y agoWow, I completely missed that (largely because I assumed a Go implementation could not guarantee constant time), sorry about that and thanks for looking deeper than I did. On that note, how much of a guarantee is there in the Go implementation? I assume in most cases it's going to be constant time, but isn't that a little harder to guarantee when compared to the asm version? And if not why not just use the Go implementation everywhere for consistency?
- deleted 10y ago[deleted]
- wbl 10y agoThe asm version is much more performant. The Go version is a port of the version in NSS, but the compiler is free to screw it up in various ways. Furthermore correctness is always a concern: cleverness in unsaturated arithmetic code can be hard.
- pbsd 10y agoWell, the Go implementation of P-256 is meant to be constant-time, even if we don't get a hard guarantee that the compiler won't screw that up somewhere somehow. On the other hand, the generic implementation of the other curves is almost comically vulnerable to timing attacks---compare [1] to [2]. [1] https://github.com/golang/go/blob/master/src/crypto/elliptic/elliptic.go#L255-L263 https://github.com/golang/go/blob/master/src/crypto/elliptic... [2] https://github.com/golang/go/blob/master/src/crypto/elliptic/p256.go#L1112-L1140 https://github.com/golang/go/blob/master/src/crypto/elliptic...