-
Notifications
You must be signed in to change notification settings - Fork 17.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
crypto/rsa: allow exponents larger than 1<<31-1 #3161
Labels
Milestone
Comments
According to http://eprint.iacr.org/2012/064.pdf, of the rsa keys gathered(~6M), 0.0248% of PGP keys (about 100) use e of 2^127+3. I think there do exist a need for large exponents, and OpenSSL use big number to represent it. |
See agl's comments on CL http://golang.org/cl/5650067: |
The standard library doesn't attempt to meet every possible need and frequently errs on the side of simplicity. In this case, large public exponents are both obscure and crpytographically illiterate and so are exactly the sort of thing that we omit. It looks like BIND's keygen utility makes it too easy to do something stupid and I'll take that up with them. For your needs, it's perfectly ok to write your own code to address corner cases. In this case, since we have math/big, it's straightforward too. |
Good point on comment #10. Right now this happens because an int cannot hold such a value, but when we move int to be 64 bits on 64-bit platforms, this will "work" but only on 64-bit machines. Better to reject the exponents explicitly everywhere. Just a note for us to remember after Go 1. Owner changed to builder@golang.org. Status changed to Accepted. |
You do not want to prevent people from interoperating. The whole "be liberal in what to accept, strict in what to send" thing. It should be supported, not behave differently on different architectures. At most, prevent people from creating keys with F5 with default options. Note that bind's dnssec-keygen -e means to ue F4, not F5. So no idea how .us managed to use F5 or why. |
ok, this is what likely happened dnssec-keygen used exponent 3, and you had to use -e to get 65537. Since there was a big fuzz about weak keys, people added "-e" to their dnssec scripts. someone at ISC changed the default from F0 to F4, but left the -e option in to mean "the next fermat prime". People upgrade their bind, and get a double whammy...... I see more zones based on F5. It is very common :( The solution would be for "-e" to get ingnored in the next dnssec-keygen release, but the damage is already done.... |
CL 6493112 is submitted, so when we convert to int being 64 bits on 64-bit machines, even there we will still reject E >= 1<<31, like we do today. That is, the 32-bit and 64-bit systems will both reject 2**32 + 1 as an exponent. The only thing left for this issue is whether we need to expand the RSA API to accommodate these giant keys in practice. It sounds like we do not, so I am updating the summary and closing this as WorkingAsIntended. agl@, please speak up if you disagree. To see if the sites were still using F5, I tried looking at the dnssec keys for .us using the dig commands in comment #3, but I cannot just look at base64 output and tell what exponent is encoded. Status changed to WorkingAsIntended. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
by remigius.gieben:
The text was updated successfully, but these errors were encountered: