/cc @agl

We certainly can't change the implementation in the near-term - there's too much to change and it's subtle. I let @agl weigh in regarding the need to do so in the first place (or not).

Putting milestone back as far as documentation is concerned.

#11499 (@agl) claims some elliptic curves (P-224 and the important P-256) do have constant-time implementations in Go (and that, in the context of TLS, others don't really pose a security risk for current certificate practice).

That contradicts my current best guess, as I see math/big used at least occasionally, even in P-256 (https://github.com/golang/go/blob/master/src/crypto/elliptic/p256.go). Math/big normalizes numbers and hence occasionally even truncates away the leading (most significant) word(s) if they are zero, which certainly cannot be constant-time. So far, I would have missed it though, if all of these usages happen to be safe for P-224 and P-256.

Documentation sounds like a very good idea---wouldn't it be good to somehow warn users that at least all elliptic curves other than P-224 and P-256 (and similarly at least generic RSA?) isn't constant-time in Go? Even users who don't stumble across #11499 (or this issue) by pure chance, maybe? Not every project limits itself to using crypto only for TLS; see notaryproject/notary#94 for nearly having tricked one into making itself unsafer by expanding to other curves.

Of course, a plan to make all this constant-time would be even better from my point of view!

I've been noting this issue for a long time. I don't mind noting it more strongly if it'll have any effect. Briefly, off the top of my head:

RSA, DSA, DH: none are constant time because math/big isn't.
P-224 and P-256: the interface involves math/big but, apart from the import/export, should be CT.
P-521: not CT as it uses big/math.
AES: generic code uses T-tables, so not CT. amd64 with AESNI is safe though.
GHASH: has tables too, so no. amd64 with AESNI is safe though.

Thank you. So what's to be done? Do you feel more CT code would be desirable?

I failed to see any note about CT/non-CT behavior in ECDSA, having turned to https://godoc.org for crypto, crypto/elliptic, crypto/ecdsa and finally the generic (non-P-224/P-256) sources.

I hadn't looked at godoc for crypto/rsa, where I now realize that at least the attribute "constant time" is used indeed and hence, by contrast, might have allowed the inference that other aspects not marked like that are not necessarily CT.

From the point of view of a user: Would it be too much to ask for a warning in the docs, rather than something to be inferred from a seemingly irrelevant sublibrary? Where should I have looked, BTW?

I sent CL 31573.

@agl, not sure about P-384 nor where to put the comment about DH.

CL https://golang.org/cl/31573 mentions this issue.

Reassigning to @rsc, as @agl has replied on https://go-review.googlesource.com/c/31573/