crypto/rsa: support for 64-bit E values

[akalin-keybase]

We at keybase have seen PGP keys in the wild that use exponents greater than signed 32-bits: keybase/go-crypto#8

Unfortunately, we've had to fork crypto/rsa and use that in our fork of golang.org/x/crypto/openpgp.

Ideally, we wouldn't have to do that. However, @agl, it looks like you deliberately limited it to 32 bits.

Would you accept a patch to change rsa.PublicKey.E to int64? If not, is there another solution you can think of?

[minux]

See also #14129. Changing the type of E violates the Go 1 API guarantee, so the best we can do is to introduce an E64 int64 field.

[agl]

It's never been the aim of the crypto libraries to support every thing that someone has managed to do somewhere. I'm sure that if E were 64 bit, someone will have turned out to have a yet larger public exponent.

Given that there is no reason to have exponents larger than 65537, and 99.9% of keys use either 3 or 65537, I don't think that this is something we want to spend time on I'm afraid.

And, although it's obviously your decision, I would recommend not forking crypto/rsa. If your barrier for supporting something is that it happened to work then I fear you'll end up with a huge mess. In this case, e=2869406037 is a rather smooth number for a public exponent. Perhaps it's fine (one can't tell without the private key) but you might be papering over a key generation bug here.

[akalin-keybase]

Ah, thanks. @rsc does this change your thinking re. there being enough reports to warrant polluting the API?

If we can't add an E64 field, then we'd be stuck with keeping our fork, unfortunately. :/

[akalin-keybase]

@agl OK, thanks for the explanation!