-
Notifications
You must be signed in to change notification settings - Fork 18k
crypto/x509: ParsePKCS1PrivateKey is not complaint with PKCS#1 standard #14512
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
Comments
The first form is very obscure and supporting it cleanly would require code to recover the primes from the private exponent. That's possible, but it's complex and thus it's unclear whether it would be worthwhile. |
(I'm going to close this unless a significant motivation arises.) |
I am currently facing the same problem. Is there some kind of workaround (maybe using openssl?) to convert the .pem file to a appropriate format? |
@fetzerms To solve the problem, I used to manual build private key, copy the crypto/rsa/pkcs1v15.go SignPKCS1v15, rewrite it to avoid check, so can be work. like this: https://play.golang.org/p/fsenJlFhQY becasue My project just need to signature verify, I don't depend OpenSSL that is so big. |
Some little updates on how i First i dumped the private key using openssl I then used a java function from Stackoverflow to convert the openssl output to a Java BigInteger (Url: http://stackoverflow.com/a/9303339). Afterwards i used another java method to calculate p and q from Stackoverflow aswell (Url: http://stackoverflow.com/a/28299742). After converting the numbers from hex to decimal, I finally used the calculated p and q values to generate a new .pem file using rsatool from github (https://github.com/ius/rsatool): The generated key.pem can be used with the x509.ParsePKCS1PrivateKey func. Maybe these steps are helpful for other people aswell. |
According to https://tools.ietf.org/html/rfc3447#section-3.2: a RSA private key may have either
of two representations: The first representation consists of a pair of n(modulus) and d(privateExponent); The second representation is made of primary factors (p, q) and CRT factors (dp, dq, qInv...). Both representation should be valid.
Go's current pkcs#1 implementation can not parse the first representation form of RSA private key. In https://github.com/golang/go/blob/release-branch.go1.6/src/crypto/x509/pkcs1.go#L39, line 54 checks n, d, p, q are all not zero.
This check makes crypto/x509.ParsePKCS1PrivateKey can only parse keys with mixture of first and second representation, such as keys generated by openssl.
I generate a key with Java bouncycastle's org.bouncycastle.jcajce.provider.asymmetric.rsa.BCRSAPrivateKey, which use the first representation. It can not be parse it by go.
But openssl can read it fine
Go version: go1.6 darwin/amd64
OS: Mac OSX 10.11.1
Openssl version: 0.9.8zg 14 July 2015
The text was updated successfully, but these errors were encountered: