Skip to content
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

Closed
gopherbot opened this issue Feb 29, 2012 · 21 comments
Closed

crypto/rsa: allow exponents larger than 1<<31-1 #3161

gopherbot opened this issue Feb 29, 2012 · 21 comments
Milestone

Comments

@gopherbot
Copy link

@gopherbot gopherbot commented Feb 29, 2012

by remigius.gieben:

Before filing a bug, please check whether it has been fixed since
the latest release: run "hg pull", "hg update default", rebuild, and
retry
what you did to
reproduce the problem.  Thanks.

What steps will reproduce the problem?
1. Run the following program

package main

import (
    "math/big"
    "crypto/rsa"
)

func main() {
    pubkey := new(rsa.PublicKey)
    pubkey.N = big.NewInt(0)
    pubkey.E = 4294967296 + 1
}



What is the expected output?
No error

What do you see instead?
./rsa.go:11: constant 4294967297 overflows int

Which compiler are you using (5g, 6g, 8g, gccgo)?
6g

Which operating system are you using?
Linux/Ubuntu 64 bits

Which revision are you using?  (hg identify)
96bd78e7d35e weekly/weekly.2012-02-22

Please provide any additional information below.
@rsc
Copy link
Contributor

@rsc rsc commented Feb 29, 2012

Comment 1:

There is no need for such large exponents.

Status changed to WorkingAsIntended.

@minux
Copy link
Member

@minux minux commented Feb 29, 2012

Comment 2:

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.
@gopherbot
Copy link
Author

@gopherbot gopherbot commented Feb 29, 2012

Comment 3 by remigius.gieben:

Could you please tell that to the people running .US:
$ dig dnskey us +dnssec
Or nic.cz:
$ dig dnskey nic.cz +dnssec
And probably others.
@rsc
Copy link
Contributor

@rsc rsc commented Feb 29, 2012

Comment 4:

See agl's comments on CL http://golang.org/cl/5650067:
@gopherbot
Copy link
Author

@gopherbot gopherbot commented Mar 1, 2012

Comment 5 by remigius.gieben:

I read the comments and I sympathize, but this is causing interop. problems. People seem
to do this and openssl allows them. BIND's dnssec-keygen even has an option to select
the F5 prime:     -e: use large exponent (RSAMD5/RSASHA1 only)
@rsc
Copy link
Contributor

@rsc rsc commented Mar 1, 2012

Comment 6:

Leaving for agl@ to decide.  We can do this after Go 1 by adding BigE or something silly
like that, and require either E==0 or BigE==nil.

Labels changed: added priority-later, removed priority-triage.

Status changed to Thinking.

@agl
Copy link
Contributor

@agl agl commented Mar 2, 2012

Comment 8:

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.
@rsc
Copy link
Contributor

@rsc rsc commented Mar 2, 2012

Comment 9:

Status changed to Unfortunate.

@gopherbot
Copy link
Author

@gopherbot gopherbot commented Mar 6, 2012

Comment 10 by remigius.gieben:

So when 'int' becomes 64 bits, this issue will be automatically fixed?
@minux
Copy link
Member

@minux minux commented Mar 6, 2012

Comment 11:

int will become 64-bit only on 64-bit systems...
@rsc
Copy link
Contributor

@rsc rsc commented Mar 6, 2012

Comment 12:

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.

@gopherbot
Copy link
Author

@gopherbot gopherbot commented Mar 6, 2012

Comment 13 by letoams:

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.
@rsc
Copy link
Contributor

@rsc rsc commented Mar 6, 2012

Comment 14:

I agree that it should behave consistently across architectures.
@gopherbot
Copy link
Author

@gopherbot gopherbot commented Mar 6, 2012

Comment 15 by letoams:

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....
@gopherbot
Copy link
Author

@gopherbot gopherbot commented Mar 25, 2012

Comment 16 by mansourmoufid:

The next bug report will be for E = 2^64+1. ;)
OP, you can also use an exponent of 2^32-5 (4294967291).
@rsc
Copy link
Contributor

@rsc rsc commented Mar 26, 2012

@rsc
Copy link
Contributor

@rsc rsc commented Sep 12, 2012

Comment 18:

CL 6493112

Status changed to Started.

@rsc
Copy link
Contributor

@rsc rsc commented Sep 12, 2012

Comment 19:

Labels changed: added go1.1.

@rsc
Copy link
Contributor

@rsc rsc commented Sep 14, 2012

Comment 20:

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.

@agl
Copy link
Contributor

@agl agl commented Sep 14, 2012

Comment 21:

.us appears to be using e=2**16+1 now.
@rsc
Copy link
Contributor

@rsc rsc commented Sep 14, 2012

Comment 22:

Thanks.
@rsc rsc added this to the Go1.1 milestone Apr 14, 2015
@rsc rsc removed the go1.1 label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants