crypto: add Equal(PublicKey) bool method to PublicKey implementations

[erahn]

What version of Go are you using (go version)?

1.9

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

Any

What did you do?

https://play.golang.org/p/DAZM324jkY

What did you expect to see?

This is a request for adding a Cmp() function to the PublicKey / PrivateKey types in the crypto library. Currently it is non-trivial to check if two public keys or two private keys are the same and requires checking the algorithms definition and manually comparing each operator. It would be much similar to have some Cmp() functions to simplify this.

What did you see instead?

This is a feature request - but not to be too cheeky - a lack of a simple way to compare two crypto keys.

[dsnet]

\cc @agl

[nhooyr]

This may be useful for the x/crypto/ssh package for public key authorization. The current approach to authorize a public key is to marshal it into the openSSH wire format and then compare those bytes against a authorized public key's (which was also marshalled into the openSSH wire format) bytes.

[rsc]

It does seem like we should do something here; it's a little hard to retrofit into the existing interfaces but we could. It seems like the operations needed are

func PrivateToPublicKey(PrivateKey) PublicKey
func PrivateKeysEqual(k1, k2 PrivateKey) bool
func PublicKeysEqual(k1, k2 PublicKey) bool

but with better names. Do I have the desired semantics correct?

[erahn]

Hello Russ, I think you have the semantics correct for the latter 2. There is a function already ( Public() ) which does the PrivateToPublicKey functionality. One thing that I wonder though is if there should be an easy function to verify if a public and private key pair match. I believe that for elliptic curves the public key is derived from the private key, but for others, such as RSA, the public key is saved alongside the private key. This can lead to issues such as: https://blog.hboeck.de/archives/888-How-I-tricked-Symantec-with-a-Fake-Private-Key.html . The problem with having Public() verify for those scenarios is that you need to verify by signing a message then verifying the signature, which may require nontrivial resources on some systems to do so. Having a separate function such as: "VerifyPublicPrivateKey( PrivateKey, PublicKey ) bool" may allow for easily resolving that issue.

…

On Mon, Oct 16, 2017 at 1:23 PM, Russ Cox ***@***.***> wrote: It does seem like we should do something here; it's a little hard to retrofit into the existing interfaces but we could. It seems like the operations needed are func PrivateToPublicKey(PrivateKey) PublicKey func PrivateKeysEqual(k1, k2 PrivateKey) bool func PublicKeysEqual(k1, k2 PublicKey) bool but with better names. Do I have the desired semantics correct? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#21704 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AX3dhsuhTVp3OUVyf-phLtNZmdoA29szks5ss7tFgaJpZM4PIHgB> .

[hanwen]

For SSH, we should have a separate conversation (if any). It basically amounts to syntactic sugar for

func Eq(a, b ssh.PublicKey) {
return 0 == bytes.Compare(a.Marshal(), b.Marshal())
}

[nhooyr]

@hanwen Wouldn't it be more efficient to compare the keys directly instead of marshalling first, assuming this issue is solved first.

[hanwen]

yes, but it would also be much more work and much more error prone.

The whole SSH protocol is marshaling data all the time to send things over the wire, so the cost of marshaling for a key comparison is neglible compared to using an SSH connection.

[nhooyr]

I'm just saying that if this issue is solved, it would also be applicable in x/crypto/ssh. It's not absolutely necessary as you have pointed out but if a function that compared two public/private keys did exist and was working well, I think it would be better to use that instead of comparing the marshalled bytes.

[ianlancetaylor]

@rsc You suggested functions above, but the crypto package today has essentially no functions. Did you mean instead something like: It could be implemented using interfaces, so that given a PrivateKey you can test whether it supports some sort of Equaler interface with an Equal method.

Does anybody want to turn this proposal into a complete suggestion, one way or another?

[erahn]

I would be interested in pursing this further. What would the next step be? I am looking at https://golang.org/doc/contribute.html and it is unclear if a full design doc is needed or if I should just submit some code to add interface functions along the lines of what @ianlancetaylor and @rsc are suggesting?

[ianlancetaylor]

@erahn The next step is a proposal for specifically how the crypto package will be changed, and how those changes will be reflected in crypto/... packages. Thanks.