No, it’s the EncryptedPrivateKeyInfo format and internally the data is PKCS8. I
can unwrap it with a cipher from SunJCE.
BTW, I made a mistake in my first mail. The config needn’t be sensitive. Then I
am able to use the key to init a SunJCE cipher.
—Weijun
> On Dec 18, 2024, at 22:02, Mike StJ
On Thu, 19 Dec 2024 02:29:07 GMT, Weijun Wang wrote:
> Just curious, if I disable the `CKM_CONCATENATE_DATA_AND_BASE` mechanism in
> the config file, then `addIKM(data).addIKM(key)` still works. I guess that's
> because the config only applies to JCA/JCE algorithms but not internal
> implement
If I had to make a wild guess, I’d guess that the wrapped key doesn’t include
the curve info. If the length of the wrapped data is only 40 bytes, then all
you have is the x from the private key. I’m wondering if the algorithm has to
include the curve info.
Something like “EC/secp256r1”?
On Wed, 18 Dec 2024 23:22:20 GMT, Martin Balao wrote:
>> We would like to propose an implementation of the HKDF algorithms for
>> SunPKCS11, aligned with the KDF API proposed for JDK 24 (see [JEP 478: Key
>> Derivation Function API
>> (Preview)](https://bugs.openjdk.org/browse/JDK-8189808)).
>
On Thu, 19 Dec 2024 00:11:34 GMT, Weijun Wang wrote:
>> Generic is a native PKCS11 key type (`CKK_GENERIC_SECRET`) that could have
>> been added to SunPKCS11 before, irrespective of HKDF. It's convenient for
>> the test to have key material in the token and test consolidation (IKM or
>> salt).
Hi, PKCS #11 gurus,
var sp = KeyPairGenerator.getInstance("EC",
p).generateKeyPair().getPrivate();
var k = KeyGenerator.getInstance("AES", p).generateKey();
var cipher = Cipher.getInstance("AES/KW/PKCS5Padding", p);
cipher.init(Cipher.WRAP_MODE, k);
var wrapped = cipher.wrap(
On Wed, 18 Dec 2024 23:31:55 GMT, Martin Balao wrote:
>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java
>> line 737:
>>
>>> 735: m(CKM_CHACHA20_POLY1305));
>>> 736: d(SKF, "Generic", P11SecretKeyFactory,
>>> 737: m(CKM_GENE
On Wed, 18 Dec 2024 22:48:04 GMT, Weijun Wang wrote:
>> Martin Balao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Unused import removed.
>>
>> Co-authored-by: Martin Balao Alonso
>> Co-authored-by: Francisco Ferrari Bihurriet
On Wed, 18 Dec 2024 21:33:29 GMT, Sean Mullan wrote:
>> We included SHA1 because there could be a legacy use case to support and
>> it's part of the test vectors for RFC 5869 (HMAC-based Extract-and-Expand
>> Key Derivation Function (HKDF)). We don't recommend using it, and will
>> probably fi
> We would like to propose an implementation of the HKDF algorithms for
> SunPKCS11, aligned with the KDF API proposed for JDK 24 (see [JEP 478: Key
> Derivation Function API
> (Preview)](https://bugs.openjdk.org/browse/JDK-8189808)).
>
> This implementation will be under the _Preview_ umbrella
On Wed, 18 Dec 2024 19:56:02 GMT, Martin Balao wrote:
>> We would like to propose an implementation of the HKDF algorithms for
>> SunPKCS11, aligned with the KDF API proposed for JDK 24 (see [JEP 478: Key
>> Derivation Function API
>> (Preview)](https://bugs.openjdk.org/browse/JDK-8189808)).
>
> Allow `Generic` as an algorithm in the `KeyAgreement::generateSecret(alg)`
> method.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
add key size adjustment clarification
-
Changes:
- all: https://git.openjdk.org/jdk
On Wed, 18 Dec 2024 19:50:26 GMT, Martin Balao wrote:
>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java
>> line 1092:
>>
>>> 1090: m(CKM_HKDF_DERIVE, CKM_HKDF_DATA));
>>> 1091: d(KDF, "HKDF-SHA512", P11KDF, m(CKM_SHA512_HMAC),
>>> 1092:
> SM Cleanup of common test library test/lib/...:
>
> Remove unnecessary catches of SecurityException
> Remove AccessController and doPrivileged from SimpleSSLContext and
> ProcessTools.
Roger Riggs has updated the pull request incrementally with one additional
commit since the last revision:
On Thu, 12 Dec 2024 04:14:22 GMT, Martin Balao wrote:
>> We would like to propose an implementation of the HKDF algorithms for
>> SunPKCS11, aligned with the KDF API proposed for JDK 24 (see [JEP 478: Key
>> Derivation Function API
>> (Preview)](https://bugs.openjdk.org/browse/JDK-8189808)).
>
> We would like to propose an implementation of the HKDF algorithms for
> SunPKCS11, aligned with the KDF API proposed for JDK 24 (see [JEP 478: Key
> Derivation Function API
> (Preview)](https://bugs.openjdk.org/browse/JDK-8189808)).
>
> This implementation will be under the _Preview_ umbrella
On Wed, 18 Dec 2024 16:38:39 GMT, Weijun Wang wrote:
> I have never been a PKCS11 expert, but the code looks fine to me. The
> `import` line at the beginning of `CK_HKDF_PARAMS.java` is useless.
Thanks for your review. Unused import removed.
> src/jdk.crypto.cryptoki/share/classes/sun/security
Nice! Thank you!
On Wed, Dec 18, 2024 at 5:57 AM Martin Balao wrote:
> On 12/18/24 05:25, Xuelei Fan wrote:> Hm, that would be nice if JIT
> could optimize it. Did you have a chance
> > to verify it?
> >
>
> Yes. For example, to verify we can do the following:
>
> 1) Debug Signature::getInst
On Thu, 12 Dec 2024 04:14:22 GMT, Martin Balao wrote:
>> We would like to propose an implementation of the HKDF algorithms for
>> SunPKCS11, aligned with the KDF API proposed for JDK 24 (see [JEP 478: Key
>> Derivation Function API
>> (Preview)](https://bugs.openjdk.org/browse/JDK-8189808)).
>
On Wed, 18 Dec 2024 17:06:02 GMT, Magnus Ihse Bursie wrote:
>> In several (most? all?) of the build system files, the copyright header
>> includes the classpath exception. This makes no sense, and should be
>> removed.
>>
>> I have removed the classpath exception from makefiles, autoconf, she
On Wed, 18 Dec 2024 17:27:24 GMT, Weijun Wang wrote:
> Will this ever happen?
>
> https://github.com/openjdk/jdk/blob/020255a72dc374ba0bdd44772047f14a8bfe69a9/test/lib/jdk/test/lib/jfr/TestClassLoader.java#L63
Yes, (my first pass removed the exception handling and tests failed).
A SecurityExcep
On Wed, 18 Dec 2024 17:01:30 GMT, Roger Riggs wrote:
>> SM Cleanup of common test library test/lib/...:
>>
>> Remove unnecessary catches of SecurityException
>> Remove AccessController and doPrivileged from SimpleSSLContext and
>> ProcessTools.
>
> Roger Riggs has updated the pull request incre
On Wed, 18 Dec 2024 17:01:30 GMT, Roger Riggs wrote:
>> SM Cleanup of common test library test/lib/...:
>>
>> Remove unnecessary catches of SecurityException
>> Remove AccessController and doPrivileged from SimpleSSLContext and
>> ProcessTools.
>
> Roger Riggs has updated the pull request incre
> In several (most? all?) of the build system files, the copyright header
> includes the classpath exception. This makes no sense, and should be removed.
>
> I have removed the classpath exception from makefiles, autoconf, shell
> scripts, properties files, configuration files, IDE support file
> SM Cleanup of common test library test/lib/...:
>
> Remove unnecessary catches of SecurityException
> Remove AccessController and doPrivileged from SimpleSSLContext and
> ProcessTools.
Roger Riggs has updated the pull request incrementally with one additional
commit since the last revision:
> JDK-8341775: In the case where there is a *single* META-INF directory but
> potentially *multiple* manifest files of different cases, print a warning
> before selecting the first one and ignoring the rest (the current behavior
> should be maintained).
>
> **Note**: We cannot (so far) pass whe
On Wed, 18 Dec 2024 15:00:13 GMT, Roger Riggs wrote:
> SM Cleanup of common test library test/lib/...:
>
> Remove unnecessary catches of SecurityException
> Remove AccessController and doPrivileged from SimpleSSLContext and
> ProcessTools.
LGTM
test/lib/jdk/test/lib/net/SimpleHttpServer.java
On Thu, 12 Dec 2024 04:14:22 GMT, Martin Balao wrote:
>> We would like to propose an implementation of the HKDF algorithms for
>> SunPKCS11, aligned with the KDF API proposed for JDK 24 (see [JEP 478: Key
>> Derivation Function API
>> (Preview)](https://bugs.openjdk.org/browse/JDK-8189808)).
>
On Wed, 18 Dec 2024 15:00:13 GMT, Roger Riggs wrote:
> SM Cleanup of common test library test/lib/...:
>
> Remove unnecessary catches of SecurityException
> Remove AccessController and doPrivileged from SimpleSSLContext and
> ProcessTools.
Looks good. I see some more in `test/lib/jdk/test/lib/
SM Cleanup of common test library test/lib/...:
Remove unnecessary catches of SecurityException
Remove AccessController and doPrivileged from SimpleSSLContext and ProcessTools.
-
Commit messages:
- 8346468: SM cleanup of common test library
Changes: https://git.openjdk.org/jdk/pull
On 12/18/24 05:25, Xuelei Fan wrote:> Hm, that would be nice if JIT
could optimize it. Did you have a chance
to verify it?
Yes. For example, to verify we can do the following:
1) Debug Signature::getInstance throughout the path that calls
Signature::getInstanceRSA and ProvidersFilter::isAl
On Tue, Dec 17, 2024 at 9:34 PM Martin Balao wrote:
> On Wed, Dec 18, 2024 at 1:39 AM Xuelei Fan wrote:
>
>> On Tue, Dec 17, 2024 at 6:45 PM Martin Balao wrote:
>>
>>> On Wed, 18 Dec 2024 00:35:38 GMT, Xue-Lei Andrew Fan
>>> wrote:
>>>
>>> > Not to mention the performance impact.
>>>
>>> I am
32 matches
Mail list logo
