crypto: Equal(PublicKey) bool methods leak to PrivateKey implementations

[andybons]

Since golang.org/cl/225460 (#21704), the following code compiles but prints an unexpected result:

package main

import (
	"crypto/rand"
	"crypto/rsa"
)

func main() {
	pk, _ := rsa.GenerateKey(rand.Reader, 512)
	println(pk.Equal(pk)) // prints false
}

This is due to PrivateKey embedding PublicKey without having its own Equal method to mask PublicKey’s.

This causes difficult to debug issues with tools like go-cmp, as it looks for an Equal method on each type recursively and finds one in this case for the concrete private key types. The diff printed by the following code will be non-empty, but the values are identical:

package main

import (
	"crypto/rand"
	"crypto/rsa"
	"fmt"
	"math/big"

	"github.com/google/go-cmp/cmp"
)

func main() {
	pk, _ := rsa.GenerateKey(rand.Reader, 512)
	bigIntCmp := cmp.Comparer(func(x, y *big.Int) bool {
		return x.Cmp(y) == 0
	})
	fmt.Printf("Diff: '%s'\n", cmp.Diff(pk, pk, bigIntCmp))
}

/cc @FiloSottile @katiehockman

[katiehockman]

I ran into the same issue with #33564 where I created a MarshalText method on ecdsa.PublicKey, which then leaked to ecdsa.PrivateKey because it embedded PublicKey.

That's unfortunate. @FiloSottile how do you want to proceed here? Make an Equal on the PrivateKey types too?

[rsc]

Nice bug. If a particular PrivateKey embeds PublicKey, then any time you implement PublicKey.M you should also implement PrivateKey.M to do the private key-specific behavior, whatever that is. Probably there should be a (non-doc) comment in the sources anywhere we do this, alerting people to the gotcha.

Embedding the PublicKey instead of calling the field Public was probably a mistake, but too late now.

[FiloSottile]

Yeah, using embedding was probably a mistake in hindsight, even if I see how it made sense since the PublicKey fields are arguably PrivateKey fields as well.

Question about Equal semantics: would you expect two equivalent PrivateKeys to return true or false if one has Precomputed set and the other doesn't? I think false?

(I was hoping to avoid the question by not implementing Equal on the private keys, but yes, too late.)

[rolandshoemaker]

Question about Equal semantics: would you expect two equivalent PrivateKeys to return true or false if one has Precomputed set and the other doesn't? I think false?

Naively I'd assume Equal compares only the key material and ignores the Precomputed field. I think one thing to consider is what the intended use of the method is, it seems likely people will use this to verify too keys are the same (i.e. similarly to marshaling to DER and comparing the encoding is equal) rather than comparing that the actual structs are equal. Either way this would be a good thing to document publicly.

(It could be somewhat confusing to consider it given ECDSA and EdDSA have no analog.)

[andybons]

Question about Equal semantics: would you expect two equivalent PrivateKeys to return true or false if one has Precomputed set and the other doesn't? I think false?

@rsc what do you think?

[rsc]

I would personally expect Equal to be semantic rather than picky about the exact representation. But if you can make an argument for being picky, that's OK with me too.

[FiloSottile]

@rsc pointed out IP.Equal and Time.Equal as precedents of Equal meaning equivalent, so let's implement it by ignoring Precomputed.

[gopherbot]

Change https://golang.org/cl/231417 mentions this issue: crypto/rsa,crypto/ecdsa,crypto/ed25519: implement PrivateKey.Equal