Constant-time big-integer support in Go standard library
(too old to reply)
Bryan Ford
2017-07-08 16:51:21 UTC
For those of you who use or might use Go for public-key crypto, there’s a GitHub discussion I’d like to draw your attention to:

proposal: math/big: support for constant-time arithmetic
https://github.com/golang/go/issues/20654 <https://github.com/golang/go/issues/20654>

The brief summary is that Go has big-integer (‘big.Int’) support in the standard library, which is used by the public-key crypto APIs in the standard library (e.g., crypto/rsa, crypto/dsa, crypto/ecdsa) - unsafely, because big.Int currently doesn’t even make any attempt to support constant-time operation. My proposal, which launched the above thread, tries to identify and begin to prototype a reasonable, backward-compatible but general way of enhancing Go’s big.Int type to support constant-time operation as needed by crypto arithmetic.

Most of the current discussion participants are Go language and/or compiler people; the discussion might benefit from the perspectives of a hard-core cryptographer or two. Especially if any of you know of “examples of interesting or important projects” using Go that would benefit from constant-time big-number arithmetic, it would be great if you could chime in.

Of course the thread’s primary focus is Go, but the discussion touches on many issues that are broadly relevant (and difficult) across languages, such as methods of testing whether the compiler-generated code “really” is constant-time with respect to sensitive inputs.

Tony Arcieri
2017-07-08 17:02:22 UTC
I think this is a good thing but would still recommend a
belt-and-suspenders approach which uses random blinding in addition to
"constant time" bignums.

The latter seem particularly hard to achieve securely in practice, with a
long history of failure.

Random blinding seems to provide a general defense against a wide range of
sidechannel attacks.
Tony Arcieri