Re: CFV: New Security Group Member: Hai-May Chao

Vote: yes --Weijun > On Jun 10, 2025, at 08:11, Sean Mullan wrote: > > I hereby nominate Hai-May Chao to Membership in the Security Group. > > Hai-May is a member of Oracle's Java Security Libraries team and has > contributed many changes to the security components of the JDK project. She >

Re: CFV: New Security Group Member: Martin Balao

Vote: yes --Weijun > On Jun 6, 2025, at 08:29, Sean Mullan wrote: > > (correcting subject title) > > I hereby nominate Martin Balao to Membership in the Security Group. > > Martin joined the Red Hat Java Platform team in 2017 as its security expert, > leading all Red Hat work related to Open

Re: X-Wing KEM

ry I didn't noticed that earlier. Thanks, Weijun > > Thank you, > Sebastian > > [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Aoverheadhunter > >> On 29. May 2025, at 18:44, Wei-Jun Wang wrote: >> >> Hi Sebastian. >> >>> On May 24, 202

Re: X-Wing KEM

Hi Sebastian. > On May 24, 2025, at 05:40, Sebastian Stenzel > wrote: > > Hi all, > > For the past few months I have been in contact with one of the authors of two > spec drafts for future JOSE encryption standards [1] [2] with the latter of > them relying on X-Wing. > > As the X-Wing spec

Re: JEP 510: HKDFParameterSpec.expandOnly(byte[] prk)

tps://www.rfc-editor.org/rfc/rfc9180#section-5.1-10 > [2]: https://datatracker.ietf.org/doc/html/rfc5869#section-3.3 > > >> On 19. May 2025, at 20:49, Wei-Jun Wang wrote: >> >> Hi Sebastian, >> >> Thanks for your interest on the KDF APIs. >> >>

Re: JEP 510: HKDFParameterSpec.expandOnly(byte[] prk)

Hi Sebastian, Thanks for your interest on the KDF APIs. As the name suggests, the PRK is a key, and we've represented it as a SecretKey. It's always complete, of fixed length, and provided in a single step. This is quite different from the IKM, which may come in various forms, or even a combin

Re: TLS support for X25519MLKEM768.

There is an enhancement at https://bugs.openjdk.org/browse/JDK-8314323. > On Apr 21, 2025, at 12:19, Azeem Jiva wrote: > > Hi, > Are there plans for TLS support for the X25519MLKEM768 key exchange in > OpenJDK? Thanks.

New JEP Draft: Key Derivation Function API

Hi all, JEP 478: Key Derivation Function API (Preview) [1] was included in JDK 24. We propose to finalize it in JDK 25 without modification. The new JEP is available at https://openjdk.org/jeps/8353275. Since JDK 24, a PKCS #11 implementation of HKDF [2] has been integrated into an early build

Re: Linux support for java.security.jgss "nativeccache" functionality

Hi Nick, I’ve filed https://bugs.openjdk.org/browse/JDK-8349546. It will be great if the same code could support nativeccache on both Mac and Linux. If the test cannot be automated, feel free to add some instructions for manual testing. Looking forward to your first OpenJDK contribution! Than

Re: On 8346720: Support Generic keys in SunPKCS11 SecretKeyFactory

8346720 in PR #22215's commit for the code changes part. My understanding is that PR #22215 will now be blocked by JDK-8346720's CSR. We look forward to having the CSR for JDK-8346720 reviewed, so we can move it to Proposed. Regards, Martin.- On Wed, Jan 8, 2025 at 9:35 PM Wei-Jun W

Re: On 8346720: Support Generic keys in SunPKCS11 SecretKeyFactory

n SunPKCS11 (Preview) (PR #22215)", so we don't have > to create dependent PRs. Has there been any plan change since we reached this > agreement? > > Regards, > Martin.- > > > On Tue, Jan 7, 2025 at 11:44 AM Wei-Jun Wang wrote: > Hi Martin, > > Ha

On 8346720: Support Generic keys in SunPKCS11 SecretKeyFactory

Hi Martin, Happy New Year! I’m currently working on 8346997: Java Security Standard Algorithm Names spec should include key algorithm names https://bugs.openjdk.org/browse/JDK-8346997 As you can see, it involves only spec changes. Some days ago, we asked you to close out 8346720: Sup

Re: Cannot wrap an EC key?

rial being wrapped was not > specified by PKCS11. > > Mike > > Sent from my iPad > >> On Dec 18, 2024, at 19:23, Wei-Jun Wang wrote: >> >> Hi, PKCS #11 gurus, >> >> var sp = KeyPairGenerator.getInstance("EC", >> p).generate

Cannot wrap an EC key?

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(

Re: How to get public key from private key in PKCS #11

receiver's private and public key, both of which are generated by the receiver. Couldn't our implementation of Decap take the key pair instead of taking the secret key alone? Regards, Daniel śr., 11 gru 2024 o 18:00 Wei-Jun Wang mailto:weijun.w...@oracle.com>> napisał(a): Hi Ma

Re: How to get public key from private key in PKCS #11

KeyStore 3. Translated by a KeyFactory In the first 2 cases, the public key is right at side. In the 3rd case, the key material is available and I can calculate the public key. Thanks, Weijun On Dec 11, 2024, at 12:00, Wei-Jun Wang wrote: Hi Martin, That’s how DH works. Unfortunately, DHKEM is not

Re: How to get public key from private key in PKCS #11

here? Regards, Martin.- On 12/10/24 00:07, Wei-Jun Wang wrote: So are you suggesting there is no such a way? I do notice that in NSS’s own HPKE implementation, the receiver needs to provide both keys [1]: SECStatus PK11_HPKE_SetupR(HpkeContext *cx, const SECKEYPublicKey *pkR, SECKEYPrivateKey

Re: How to get public key from private key in PKCS #11

-dJsqSgUuLEW8yqzvuB4Qwj5ay4afqgvAfvn3DiGx9lz31XjKDuAt_LABjdrwdCT8FmTTozigB-E$ Regards, -- Francisco On 12/10/24 01:43, Wei-Jun Wang wrote: Daniel suggested CKA_PUBLIC_KEY_INFO but it’s not available in NSS 3.101. On Dec 9, 2024, at 08:07, Wei-Jun Wang wrote: Hi PKCS #11 gurus, DHKEM [1] requires a

Re: How to get public key from private key in PKCS #11

Daniel suggested CKA_PUBLIC_KEY_INFO but it’s not available in NSS 3.101. On Dec 9, 2024, at 08:07, Wei-Jun Wang wrote: Hi PKCS #11 gurus, DHKEM [1] requires a function Pk(skX): The KEM public key corresponding to the KEM private key skX. "The notation pk(skX), depending on its use an

How to get public key from private key in PKCS #11

Hi PKCS #11 gurus, DHKEM [1] requires a function Pk(skX): The KEM public key corresponding to the KEM private key skX. "The notation pk(skX), depending on its use and the KEM and its implementation, is either the computation of the public key using the private key, or just syntax expressing

Re: Plans for including NIST post-quantum cryptography in Open JDK?

Hi John, We are working on adding supports for ML-DSA [1] in OpenJDK. Hopefully they can be added next year. We will then be able to sign and verify a JAR file using ML-DSA. Also, we added HSS/LMS support back in JDK 21. While OpenJDK’s builtin implementation only includes the verification par

Re: RFC: Remove Kerberos CLI tools from OpenJDK bin folder

Hi Bruno, I don’t quite understand the motivation. When you say "The presence of these CLI tools can cause conflicts with native versions provided by the operating system”, what is the operating system you are referring to? For example, many *nix systems come preinstalled with its own kinit, bu

JEP drafts: ML-KEM and ML-DSA

Hi All, We are working on implementing 2 PQC algorithms, ML-KEM and ML-DSA, in OpenJDK. New standard names and parameter set names will be defined. You can read the JEP drafts at https://openjdk.org/jeps/8339009 and https://openjdk.org/jeps/8339010. Feel free to add any comment here. Thanks,

Re: [BUG] JGSS is querying wrong realm for service ticket and fails ultimately

Hi Michael, Java starts from the default KDC and it expects a referral could happen. Does MIT krb5 always start from the client’s own KDC? If you change the default realm to AD001.SIEMENS.NET, does it work? Does it work with your other scenarios? Thanks, Max On Aug 3

Re: Missing element-list for https://docs.oracle.com/javase/8/docs/jre/api/security/jgss/spec

Adding javadoc-...@openjdk.org , but I heard "element-list" only came in with modules in JDK 9. --Weijun > On May 31, 2024, at 5:51 AM, Osipov, Michael (IN IT IN) > wrote: > > Guys, > > can someone upload element-list for that API? Javadoc fails to link to it:

Re: [Bug] javax.security.auth.kerberos.KeyTab returns unrequested keys

y. If a program wants to work with a case-sensitive KDC that really has service names only differ in case, please just turn this system property on. Thanks, Weijun > On May 7, 2024, at 7:27 AM, Wei-Jun Wang wrote: > > I'm thinking of the opposite. > >> On May 6, 2024,

Re: Add ToolProvider interface implementation keytool

We had a proposal for this at https://bugs.openjdk.org/browse/JDK-6539136 and it's also withdrawn. I've added some comments to it. Keytool is quite different from other tools because it's interactive and involves keystore and passwords. Thanks, Weijun > On May 7, 2024, at 6:16 AM, Wojtek wrote

Re: [Bug] javax.security.auth.kerberos.KeyTab returns unrequested keys

I'm thinking of the opposite. > On May 6, 2024, at 3:59 PM, Osipov, Michael (IN IT IN) > wrote: > > On 2024-05-06 21:55, Wei-Jun Wang wrote: >> Hi Michael, >> Thanks for the report. It seems not conforming to the RFC strictly >> but I hesitate to make a

Re: [Bug] javax.security.auth.kerberos.KeyTab returns unrequested keys

I'll probably pick #2 if you also like it. > On May 6, 2024, at 3:59 PM, Osipov, Michael (IN IT IN) > wrote: > > On 2024-05-06 21:55, Wei-Jun Wang wrote: >> Hi Michael, >> Thanks for the report. It seems not conforming to the RFC strictly >> but I hesitate t

Re: [Bug] javax.security.auth.kerberos.KeyTab returns unrequested keys

Hi Michael, Thanks for the report. It seems not conforming to the RFC strictly but I hesitate to make a change now. The getKeys() method uses the PrincipalName.match() method to compare principal names in case-insensitive style. The same method is also used to locate a ticket from a ccache fil

Re: Canonical/portable way to obtain long term key for a GSS security context (acceptor side)

> On May 6, 2024, at 2:55 PM, Osipov, Michael (IN IT IN) > wrote: > > Hi Weijun, > > On 2024-05-06 20:51, Wei-Jun Wang wrote: >> Hi Michael, >> I see you've just reported a bug on KeyTab. Is that your latest workaround >> to the request here? Th

Re: Canonical/portable way to obtain long term key for a GSS security context (acceptor side)

Hi Michael, I see you've just reported a bug on KeyTab. Is that your latest workaround to the request here? That's also the only one I can think of now. BTW, when you said "disjoint to the security context", the long term key of the server *is* not related to any context. Thanks, Weijun > On

Re: Potential issues with javax.crypto under StructuredTaskScope/JDK22

Can you try recording the challenge and the answer in each round and then recalculate them in a plain single thread standalone program to verify if the answers are still the same? (Hopefully this calculation is deterministic). --Weijun > On May 2, 2024, at 4:18 PM, Chris Marshall wrote: > > H

Re: [External] : Re: New Draft of the KDF JEP for the Java Platform

> On Mar 12, 2024, at 6:34 PM, Martin Balao wrote: > > As I understand it, it's not that state is not maintained but that we are > keeping it on the parameters side. For example, a extraction phase call will > generate a PRK that will be kept in the parameters side for the following > expansi

Re: Improving logging in Krb5LoginModule

hat else you are interested in. Thanks, Weijun > > Best, > Peter > > > Wei-Jun Wang ezt írta (időpont: 2024. márc. 11., H, > 16:40): > In fact, I've started working on it, see > https://github.com/openjdk/jdk/pull/18199. > > --Weijun > > > On Mar 11,

Re: Improving logging in Krb5LoginModule

In fact, I've started working on it, see https://github.com/openjdk/jdk/pull/18199. --Weijun > On Mar 11, 2024, at 9:21 AM, Wei-Jun Wang wrote: > > I've filed https://bugs.openjdk.org/browse/JDK-8327818. > > But first, in order to make sure the debug option in Krb

Re: Improving logging in Krb5LoginModule

sitive information like passwords or secret keys, so maybe there is a little danger to cover them with `-Djava.security.debug=all`. Thanks, Weijun > On Mar 11, 2024, at 5:43 AM, Sean Coffey wrote: > > > On 10/03/2024 16:01, Wei-Jun Wang wrote: >> Hi Seán, >> >> I

Re: Improving logging in Krb5LoginModule

Hi Seán, I know you are working on enhancing the security debug output with timestamps and thread info now. Do you think it can also cover Kerberos? Traditionally, Kerberos debugging is independent of other security areas and itself is quite complicated. It includes the "debug" label in JAAS Lo

Re: HttpURLConnection cache issues leading to crashes in JGSS w/ native GSS introduced by 8303809

Hi Nico, I've filed a bug at https://bugs.openjdk.org/browse/JDK-8318599. Will look into it. Thanks, Max > On Oct 19, 2023, at 10:39 PM, Nico Williams > wrote: > > Also, a colleague informs me that 17.0.5 (as packaged by Debian) w/o > `-Djdk.spnego.cache=false` doesn't exhibit the double-fr

Proposing the getParams method in PublicKey and PrivateKey

Hi All, Currently, every algorithm-specific asymmetric key interface (Ex: ECKey) in JDK has a getParams() method. We are thinking about duplicating this method in PublicKey and PrivateKey (returning null by default) so the method is available for all asymmetric keys. Once we have this method, e

Re: KrbException exception does not contain error string although error is well-known

s are necessary here with two JBS issues? > > M > > On 2023-09-20 20:06, Wei-Jun Wang wrote: >> I'll look into it. Thanks! >> Do you have a patch? :-) >> --Max >>> On Aug 9, 2023, at 3:30 AM, Osipov, Michael (SMD IT IN) >>> wrote: >>>

Re: KrbException exception does not contain error string although error is well-known

I'll look into it. Thanks! Do you have a patch? :-) --Max > On Aug 9, 2023, at 3:30 AM, Osipov, Michael (SMD IT IN) > wrote: > > Folks, Max, > > consider the following code snippet configured with the Krb5LoginModule: >> LoginContext lc = new LoginContext(loginEntryName); >> lc.login(); > >

Re: RFD: Services lockdown for security providers

r SunPKCS11 -> SUN) would lead to SUN bringing the implementation. > What we propose is a way to cherry-pick what we want (or what we don't) from > each security provider in a configurable way. > > Regards, > Martin.- > > > On 5/24/23 18:30, Wei-Jun Wang wrote: &g

Re: RFD: Services lockdown for security providers

> On May 24, 2023, at 5:03 PM, Martin Balao wrote: > >>> To better illustrate, let's say that the user requires that all >>> cryptographic operations are performed in a Hardware Security Module (HSM). >>> On the OpenJDK side, this means that the implementation for Cipher, >>> Signature, Mac

Re: JEP draft: Leighton-Micali Hash-Based Signatures

R at https://bugs.openjdk.org/browse/JDK-8305973. Thanks, Max > On Mar 20, 2023, at 5:51 PM, Wei-Jun Wang wrote: > > Hi All, > > We propose to add support for HSS/LMS as a Signature algorithm to JCA/JCE. > > All currently widely used digital signature schemes, including DSA, RSA

Re: RFR: 8303410: Remove ContentSigner APIs and jarsigner -altsigner and -altsignerpath options [v4]

IIUC there is no place to add a reviewer's name. As long as you follow the steps in https://openjdk.org/guide/#release-notes, someone reviews it, and the state becomes Delivered, I think it's done. Thanks, Weijun > On Apr 13, 2023, at 7:14 AM, Eirik Bjorsnos wrote: > > On Thu, 9 Mar 2023 18:5

Re: Update to JEP draft: Key Encapsulation Mechanism API

Hi All, The JEP draft was just updated again. The KEMParameterSpec argument is moved from getInstance() to newEncapsulator() and newDecapsulator(). The reason is that when delayed provider selection happens, a KEMSpi object is only created when newEncapsulator/newDecapsulator is called. If the

JEP draft: Leighton-Micali Hash-Based Signatures

Hi All, We propose to add support for HSS/LMS as a Signature algorithm to JCA/JCE. All currently widely used digital signature schemes, including DSA, RSA, ECDSA, and EdDSA, have the potential to be broken if large scale quantum computers are ever built. However, the security of HSS/LMS depends

Re: Update to JEP draft: Key Encapsulation Mechanism API

able length shared-secret sizes, so > having the ability to be flexible is needed. Looks like you have covered > all possible cases here. > > Thanks for these additions! > > Cheers, > > John Gray > Entrust > > > -----Original Message- > From: security-

Re: Update to JEP draft: Key Encapsulation Mechanism API

of OpenJDK, all ciphers requires the algorithm name to be thing they recognize. Thanks, Max > Btw I like the simplification. > > Gruss > Bernd > -- > http://bernd.eckenfels.net > Von: security-dev im Auftrag von Wei-Jun > Wang > Gesendet: Freitag, März 3, 2023 6:31 PM &

Re: Update to JEP draft: Key Encapsulation Mechanism API

Hi All, The JEP draft was just updated again. The major change is that there is no more DerivedKeyParameterSpec class. Maybe it's because of the name, but we found many people treating it as a place to configure the KDF used inside a KEM. Actually the only usage of it is to give caller a chanc

Re: Remove com.sun.jarsigner package with related options

Hi Eirik, I've filed https://bugs.openjdk.org/browse/JDK-8303410. This needs a CSR and a release note. Do you volunteer to write them? If yes, you can write as comments in the PR and I can move them into JBS. You can look at the CSRs for the 2 related bugs. Thanks, Weijun > On Feb 28, 2023, a

Re: Update to JEP draft: Key Encapsulation Mechanism API

On Feb 5, 2023, at 1:24 AM, Xuelei Fan wrote: > > > On Sat, Feb 4, 2023 at 2:33 PM Wei-Jun Wang wrote: > Hi Xuelei, > > This is a very interesting case since both crypto primitives (KEM and Cipher) > require delayed provider selection. > > I would say line 4 should

Re: Update to JEP draft: Key Encapsulation Mechanism API

ere are two providers, and > provider A is preferred, will the application that use “ZES” work as expected > (choose provider B)? Per the current JEP, It looks like provider A will be > selected at line 3, and exception could be thrown at line 4. > > Thanks, > Xuelei > >

Update to JEP draft: Key Encapsulation Mechanism API

; [3] https://www.rfc-editor.org/rfc/rfc5990#appendix-A.2 [4] https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/example-files/api-notes.pdf > On Jan 25, 2023, at 2:24 PM, Wei-Jun Wang wrote: > > Hi All, > > We are working on providing a new API for KE

Re: Pem util javadoc has copy and paste problem

https://bugs.openjdk.org/browse/JDK-8301299 filed. Thanks. > On Jan 28, 2023, at 2:05 AM, Bernd Eckenfels wrote: > > Hello, > > I think this Javadoc comment for the class does not belong there? > > https://github.com/openjdk/jdk/blob/391c2bb03a375dc22e416e6d1c015b86bbb958f7/src/java.base/share

Re: Resurrect VerifySignedJar test

https://bugs.openjdk.org/browse/JDK-8301167 filed. Thanks. > On Jan 25, 2023, at 12:49 PM, Eirik Bjørsnøs wrote: > > Hi, > > Can I get help filing a JBS issue for the following PR which > resurrects the VerifySignedJar test now that SHA-1 is disabled: > > https://github.com/openjdk/jdk/pull/1

Re: JEP draft: Key Encapsulation Mechanism API

> On Jan 26, 2023, at 12:48 AM, Xuelei Fan wrote: > > >> On Jan 25, 2023, at 8:43 PM, Wei-Jun Wang wrote: > > >> If someone really cares about the result of getProvider(), they should be >> careful no other thread calls encapsulation or decapsulation. >

Re: JEP draft: Key Encapsulation Mechanism API

s determined then it will not change. When designing KEM, we think this is unnecessary. Of course this makes the class more mutable. If someone really cares about the result of getProvider(), they should be careful no other thread calls encapsulation or decapsulation. Thanks, Max >

Re: JEP draft: Key Encapsulation Mechanism API

plicated SPIs by using java.util.ServiceLoade. > > Xuelei > >> On Jan 25, 2023, at 11:24 AM, Wei-Jun Wang wrote: >> >> Hi All, >> >> We are working on providing a new API for KEM (Key Encapsulation Mechanism). >> There will be a KEM class for users alon

JEP draft: Key Encapsulation Mechanism API

Hi All, We are working on providing a new API for KEM (Key Encapsulation Mechanism). There will be a KEM class for users along with a KEMSpi class for security providers, and several other parameter and exception classes. You can read the draft JEP at https://openjdk.org/jeps/8301034. Feel fre