You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to request support for getting an ECPublicKey from an ECPrivateKey when the private key is provided in PKCS8EncodedKeySpec instance, using the keyFactory.generatePublic method.
Issue:
I am currently working with EC keys and have been able to successfully derive the public key from the private key in other languages (Python, Go). However, I am unable to achieve this in Java/Kotlin due to the current restrictions in the available key specifications (ECPublicKeySpec and X509EncodedKeySpec).
Currently If I try the following code:
val privateKey64 ="MEECAQAwEwYHKoZIzj0CAQYIKoZIzj0DAQcEJzAlAgEBBCAMM3sUprvk/VVF3vXhYcY0Vi9Ay1UPd4GLoBV/htAf2w=="val decodedKey =Base64.getDecoder().decode(privateKey64)
val keySpec =PKCS8EncodedKeySpec(decodedKey)
val keyFactory =KeyFactory.getInstance("EC")
val privateKey:PrivateKey= keyFactory.generatePrivate(keySpec)
val publicKey = keyFactory.generatePublic(keySpec)
println("Private Key: ${privateKey.encoded.encodeBase64()}")
println("Public Key: ${publicKey.encoded.encodeBase64()}")
it will throw an exception: java.security.spec.InvalidKeySpecException: Must use ECPublicKeySpec or X509EncodedKeySpec; was java.security.spec.PKCS8EncodedKeySpec
In this case both the private key and the algorithm already exist in keySpec, generating the public key should be possible.
Proposal:
When PKCS8EncodedKeySpec used with engineGeneratePublic try to get the private key and generate the public key from it:
@OverrideprotectedPublicKeyengineGeneratePublic(KeySpeckeySpec) throwsInvalidKeySpecException {
if (keySpec == null) {
thrownewInvalidKeySpecException("keySpec == null");
}
if (keySpecinstanceofECPublicKeySpec) {
returnnewOpenSSLECPublicKey((ECPublicKeySpec) keySpec);
} elseif (keySpecinstanceofX509EncodedKeySpec) {
returnOpenSSLKey.getPublicKey((X509EncodedKeySpec) keySpec, NativeConstants.EVP_PKEY_EC);
} elseif (keySpecinstanceofPKCS8EncodedKeySpec) {
returnOpenSSLKey.getPublicFromPrivate(...)
}
thrownewInvalidKeySpecException("Must use ECPublicKeySpec or X509EncodedKeySpec; was "
+ keySpec.getClass().getName());
}
When PKCS8EncodedKeySpec used with engineGeneratePublic try to get the private key and generate the public key from it
I don't think we can abuse the API that way, it's certainly not what it was intended to do and is potentially quite dangerous.
There's a 1:1 mapping between KeySpecs and their Keys, and the difference between PKCS#8 and X.509 encodings helps prevent errors where developers mix up keys. But if calling getPublic() on a private KeySpec "just works" and derives a public key, for any class of keys, then it would mask such errors.
How do you suggest to get the public key from the private key without using an extra dependence like BouncyCastle by using conscrypt as security provider?
Hi
I would like to request support for getting an
ECPublicKey
from anECPrivateKey
when the private key is provided inPKCS8EncodedKeySpec
instance, using thekeyFactory.generatePublic
method.Issue:
I am currently working with EC keys and have been able to successfully derive the public key from the private key in other languages (Python, Go). However, I am unable to achieve this in Java/Kotlin due to the current restrictions in the available key specifications (
ECPublicKeySpec
andX509EncodedKeySpec
).Currently If I try the following code:
it will throw an exception:
java.security.spec.InvalidKeySpecException: Must use ECPublicKeySpec or X509EncodedKeySpec; was java.security.spec.PKCS8EncodedKeySpec
In this case both the private key and the algorithm already exist in
keySpec
, generating the public key should be possible.Proposal:
When
PKCS8EncodedKeySpec
used withengineGeneratePublic
try to get the private key and generate the public key from it:This my current workaround: stackoverflow
Other languages, libraries:
Python Cryptography
Go
The text was updated successfully, but these errors were encountered: