On Fri, 6 Dec 2024 18:03:40 GMT, Weijun Wang wrote:
>> Martin Balao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Algorithms renamed for alignment with SunJCE.
>>
>> Co-authored-by: Martin Balao Alonso
>> Co-authored-by: Franci
On Fri, 6 Dec 2024 18:34:00 GMT, Weijun Wang wrote:
>> Martin Balao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Algorithms renamed for alignment with SunJCE.
>>
>> Co-authored-by: Martin Balao Alonso
>> Co-authored-by: Franci
On Tue, 10 Dec 2024 09:31:21 GMT, Prasanta Sadhukhan
wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert changes to binary files
>
> not sure why client label is added, no java.desktop/accessibility files
On Mon, 9 Dec 2024 12:30:19 GMT, Magnus Ihse Bursie wrote:
> Some files have been modified in 2024, but the copyright year has not been
> properly updated. This should be fixed.
>
> I have located these modified files using:
>
> git log --since="Jan 1" --name-only --pretty=format: | sort -u >
On Fri, 6 Dec 2024 18:40:04 GMT, Weijun Wang wrote:
> I set CKA_EXTRACTABLE = false and generate an AES key and its `getEncoded` is
> null. Then I use it as an IKM for HKDF and the `deriveKey` output is still
> unextractable. So far so good, but if I call `deriveData` on the same input
> spec,
> 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
BTW, while I still cannot find a PKCS #11 function to get the public key, I
have a workaround now inside JDK. Please confirm if this is correct.
It looks like there are 3 cases in SunPKCS11 where a P11PrivateKey is created:
1. As a part of a newly generated key pair
2. Read from a PKCS11 KeyStor
On Mon, 9 Dec 2024 15:42:57 GMT, Magnus Ihse Bursie wrote:
>> Some files have been modified in 2024, but the copyright year has not been
>> properly updated. This should be fixed.
>>
>> I have located these modified files using:
>>
>> git log --since="Jan 1" --name-only --pretty=format: | sor
On Fri, 6 Dec 2024 19:36:09 GMT, Francisco Ferrari Bihurriet
wrote:
> Hi, this pull request implements the fixes for bugs and inconsistencies
> described in [JDK-8345139](https://bugs.openjdk.org/browse/JDK-8345139 "Fix
> bugs and inconsistencies in the Provider services map").
>
> New s
Hi Weijun,
I am not familiar to this algorithm but the typical key-exchange APIs
let you generate a key pair first and, when you invoke the secret
encapsulation mechanism, you use your private key + your counter-part
public key. Do you think this could be the case here?
Regards,
Martin.-
O
On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and locals that trigger the
>> u
Hi Martin,
That’s how DH works. Unfortunately, DHKEM is not simply exposing DH in KEM API.
Its decapsulation function is defined as [1]
def Decap(enc, skR):
pkE = DeserializePublicKey(enc)
dh = DH(skR, pkE)
pkRm = SerializePublicKey(pk(skR))
kem_context = concat(enc, pkRm)
shared_se
> 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 Mon, 9 Dec 2024 13:02:15 GMT, Magnus Ihse Bursie wrote:
> Some files have been modified in 2024, but the copyright year has not been
> properly updated. This should be fixed.
>
> I have located these modified files using:
>
> git log --since="Jan 1" --name-only --pretty=format: | sort -u >
On Mon, 9 Dec 2024 21:02:03 GMT, Magnus Ihse Bursie wrote:
>> Some files have been modified in 2024, but the copyright year has not been
>> properly updated. This should be fixed.
>>
>> I have located these modified files using:
>>
>> git log --since="Jan 1" --name-only --pretty=format: | sor
On Mon, 9 Dec 2024 15:42:57 GMT, Magnus Ihse Bursie wrote:
>> Some files have been modified in 2024, but the copyright year has not been
>> properly updated. This should be fixed.
>>
>> I have located these modified files using:
>>
>> git log --since="Jan 1" --name-only --pretty=format: | sor
On Wed, 11 Dec 2024 22:59:29 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, 12 Dec 2024 01:10:04 GMT, Weijun Wang wrote:
>> Martin Balao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Make EMPTY_KEY static.
>>
>> Co-authored-by: Martin Balao Alonso
>> Co-authored-by: Francisco Ferrari Bihurriet
On Thu, 12 Dec 2024 02:13:41 GMT, Martin Balao wrote:
>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KDF.java line
>> 154:
>>
>>> 152: long saltType = CKF_HKDF_SALT_NULL;
>>> 153: byte[] saltBytes = null;
>>> 154: P11Key p11SaltKey = null;
>>
>> For `Ex
On Fri, 6 Dec 2024 19:36:09 GMT, Francisco Ferrari Bihurriet
wrote:
> Hi, this pull request implements the fixes for bugs and inconsistencies
> described in [JDK-8345139](https://bugs.openjdk.org/browse/JDK-8345139 "Fix
> bugs and inconsistencies in the Provider services map").
>
> New s
On Wed, 11 Dec 2024 19:08:52 GMT, Anthony Scarpino
wrote:
>> Hi, this pull request implements the fixes for bugs and inconsistencies
>> described in [JDK-8345139](https://bugs.openjdk.org/browse/JDK-8345139 "Fix
>> bugs and inconsistencies in the Provider services map").
>>
>> New servic
Hi Weijun,
I didn't read the entire RFC, but it looks to me that the Decap
function is run on the receiver side, and needs the 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 alon
Sorry - missed this before.
On 12/5/2024 4:50 PM, Sean Mullan wrote:
... clipped
On 11/30/24 8:11 PM, Michael StJohns wrote:
I'm wondering if it would make sense to create a public interface
that these closed off implementation or factory classes could
implement that would allow for the retri
> 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 Thu, 12 Dec 2024 03:08:30 GMT, Weijun Wang wrote:
>> For Expand, `salt` should be `null`. Do you mean adding or hitting an
>> assertion?
>
> Assertion on line 162 will throw an NPE.
Ah, you're right, the assertion throws an NPE. Fixed.
-
PR Review Comment: https://git.openjdk.o
25 matches
Mail list logo
