math/big: r.Exp(x, 1, m) wrong if r is initially non-zero

[karalabe]

For an exponent of 1, big.Int.Exp returns the correct value only for a 0 recipient, and an off-by-one result for all pre-allocated recipients.

package main

import (
	"fmt"
	"math/big"
)

func main() {
	base := new(big.Int)
	base.SetString("84555555300000000000", 10)

	mod := new(big.Int)
	mod.SetString("66666670001111111111", 10)

	fmt.Printf("%v\n", big.NewInt(0).Exp(base, big.NewInt(1), mod))
	fmt.Printf("%v\n", big.NewInt(1).Exp(base, big.NewInt(1), mod))
}

The result in both cases above should be the same, however, they are 17888885298888888889
vs. 17888885298888888888. Playground: https://play.golang.org/p/uSBvGkeGkN

Issue originally found by @guidovranken, no security implication according to @rsc.

[ALTree]

This is caused by an aliasing issue in (z nat) divLarge(u, uIn, v nat). More specifically, divLarge does not protect itself against z and u aliasing each other.

This line:

q = z.make(m + 1)

will cause q and z to share the same backing array when m+1 <= cap(z).

Later, we do compute the quotient in pieces and set for several times q[j] = qhat, but this will modify u, because q and z share the same backing array and z aliases u, so modifying q will mess up u (this is not okay because at that point we are already storing computation state into u).

This does not happen when z is zero because in that case z.make(m+1) won't reuse z's backing array (because there isn't one).

I think we can fix this by checking for z and u aliasing in divLarge and acting accordingly.

[gopherbot]

Change https://golang.org/cl/78995 mentions this issue: math/big: protect aganist aliasing in nat.divLarge

[rsc]

To expand on the “no security implication” note:

Thanks to @karalabe for reporting this to us first at security@golang.org. We investigated and found that this only affects (1) calls that reuse a pre-allocated receiver, and (2) the specific case Exp(x, 1, m), that is, x^1 mod m.

Most crypto code uses new(big.Int).Exp(x, y, m) instead of reusing receivers. Most crypto code is also written so that a modular exponentiation with an exponent of 1 is either completely impossible or exceedingly unlikely. We examined all the uses in the standard library and believe they are unaffected, for either the first or the second reason.

In x/crypto, openpgp and ssh are clearly fine (they only use new(big.Int).Exp).

x/crypto/bn256 and x/crypto/otr may need closer examination.

[karalabe]

@rsc We've investigated x/crypto/bn256 even before opening the bug report and couldn't find anything obviously wrong with it (that's not to say there isn't, but Exp isn't a common operation there).

[p-kraszewski]

The big question is: do applications using crypto.tls or crypto.x509 - and facing the Internet - need recompilation upon patching of math/big?

[gopherbot]

Change https://golang.org/cl/81055 mentions this issue: math/big: clean up z.div(z, x, y) calls

[gopherbot]

Change https://golang.org/cl/88322 mentions this issue: [release-branch.go1.9] math/big: protect against aliasing in nat.divLarge

[gopherbot]

Change https://golang.org/cl/89156 mentions this issue: [release-branch.go1.8] math/big: protect against aliasing in nat.divLarge