This project makes use of Java and C/C++. This project will create OpenJCEPlus and OpenJCEPlusFIPS cryptographic providers which are implementations of the Java™ Cryptography Extensions (JCE) APIs. The actual cryptographic code will come from the OpenCryptographyKitC project which is based on OpenSSL.
A intermittent problem has been observed as follows:
java.security.spec.InvalidKeySpecException: Inappropriate key specification: Failed to create XEC private key
at openjceplus@11/com.ibm.crypto.plus.provider.XDHKeyFactory.engineGeneratePrivate(XDHKeyFactory.java:112)
at java.base/java.security.KeyFactory.generatePrivate(KeyFactory.java:384)
at openjceplus@11/ibm.jceplus.junit.base.BaseTestXDH.runBasicTest(BaseTestXDH.java:246)
at openjceplus@11/ibm.jceplus.junit.base.BaseTestXDH.runBasicTests(BaseTestXDH.java:205)
at openjceplus@11/ibm.jceplus.junit.base.BaseTestXDH.testXDH_runBasicTests(BaseTestXDH.java:60)
Key encodings that have been encountered for XDH based keys include:
[octet-string[octet-string[key-bytes]]]
[octet-string[key-bytes]]
Case 1 above occurs when keys are encoding from the SunEC provider on releases older then Java 17.
Case 2 above occurs when keys are generated by OpenJCEPlus or the SunEC provider on Java 17 or higher.
The encoding logic was updated to fix a corner case where a random key value contained a nested octet string just by chance. When this occured a key value was parsed that was not the correct length causing the above bad key specification when the key bytes were formatted for use with the Open Cryptography Kit C library. This update checks that key lengths are correct after parsing a nested octet string. If the length is not correct we will attempt to use a single octet format encoding.
An additional interoperability test was added to perform XDH encoding works with encoding produced by the SunEC provider for X448 and X25519 named curves.
The CurveUtil class was simplified to store known key sizes and known der encoding sizes for a given named curve.
JinhangZhang
commented
1 month ago
A intermittent problem has been observed as follows:
Key encodings that have been encountered for XDH based keys include:
Case 1 above occurs when keys are encoding from the SunEC provider on releases older then Java 17.
Case 2 above occurs when keys are generated by OpenJCEPlus or the SunEC provider on Java 17 or higher.
The encoding logic was updated to fix a corner case where a random key value contained a nested octet string just by chance. When this occured a key value was parsed that was not the correct length causing the above bad key specification when the key bytes were formatted for use with the Open Cryptography Kit C library. This update checks that key lengths are correct after parsing a nested octet string. If the length is not correct we will attempt to use a single octet format encoding.
An additional interoperability test was added to perform XDH encoding works with encoding produced by the SunEC provider for X448 and X25519 named curves.
The CurveUtil class was simplified to store known key sizes and known der encoding sizes for a given named curve.