On Mon, 2 Aug 2021 19:31:54 GMT, Martin Balao wrote:
> As described in JDK-8271566 [1], this patch proposal is intended to fix a
> problem that arises when using DSA keys that have a 256-bits (or larger) G
> parameter for signatures (either signing or verifying). There were some
> incorrect as
On Thu, 22 Jul 2021 22:52:14 GMT, Anthony Scarpino
wrote:
>> Yes, I know. Basically, we are trying to optimize performance by trying to
>> write into the supplied buffers (out) as much as we can. But then when tag
>> verification failed, the "written" bytes are erased w/ 0. Ideal case would
>
On Fri, 30 Jul 2021 18:40:14 GMT, Smita Kamath wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java
>> line 717:
>>
>>> 715: in = new byte[Math.min(PARALLEL_LEN, srcLen)];
>>> 716: out = new byte[Math.min(PARALLEL_LEN, srcLen)];
>>
On Thu, 22 Jul 2021 17:57:13 GMT, Anthony Scarpino
wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java
>> line 761:
>>
>>> 759: }
>>> 760:
>>> 761: dst.put(out, 0, rlen);
>>
>> This looks belong to the above if-block? I wonder how this
On Thu, 22 Jul 2021 17:16:45 GMT, Anthony Scarpino
wrote:
>> Seems strange to have GCMOperation op defined in GCMEngine but not
>> initialized, nor used. The methods in GCMEngine which use op has an argument
>> named op anyway. Either you just use the "op" field (remove the "op"
>> argument)
On Thu, 22 Jul 2021 17:19:20 GMT, Anthony Scarpino
wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java
>> line 650:
>>
>>> 648: int originalOutOfs = 0;
>>> 649: byte[] in;
>>> 650: byte[] out;
>>
>> The name "in", "out" are almost used
On Thu, 22 Jul 2021 18:30:50 GMT, Anthony Scarpino
wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java
>> line 762:
>>
>>> 760:
>>> 761: dst.put(out, 0, rlen);
>>> 762: processed += srcLen;
>>
>> It seems that callers of this implGCMCr
On Thu, 22 Jul 2021 18:36:16 GMT, Anthony Scarpino
wrote:
>> Hmm ok, so if it's not decryption in-place, then output buffer would still
>> be zero'ed when the auth tag failed, but this is ok?
>
> This is able in-place, not about two separate buffers.. zeroing happens
> somewhere else for all d
On Wed, 14 Jul 2021 21:02:01 GMT, Smita Kamath wrote:
>> I would like to submit AES-GCM optimization for x86_64 architectures
>> supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES
>> and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
On Wed, 14 Jul 2021 21:02:01 GMT, Smita Kamath wrote:
>> I would like to submit AES-GCM optimization for x86_64 architectures
>> supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES
>> and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
On Fri, 16 Jul 2021 00:32:16 GMT, Valerie Peng wrote:
>> Smita Kamath has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Updated AES-GCM intrinsic to match latest Java Code
>
> src/java.base/share/c
On Wed, 14 Jul 2021 21:02:01 GMT, Smita Kamath wrote:
>> I would like to submit AES-GCM optimization for x86_64 architectures
>> supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES
>> and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
On Wed, 14 Jul 2021 21:02:01 GMT, Smita Kamath wrote:
>> I would like to submit AES-GCM optimization for x86_64 architectures
>> supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES
>> and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
On Wed, 14 Jul 2021 21:02:01 GMT, Smita Kamath wrote:
>> I would like to submit AES-GCM optimization for x86_64 architectures
>> supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES
>> and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
On Wed, 14 Jul 2021 21:02:01 GMT, Smita Kamath wrote:
>> I would like to submit AES-GCM optimization for x86_64 architectures
>> supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES
>> and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
On Wed, 14 Jul 2021 21:02:01 GMT, Smita Kamath wrote:
>> I would like to submit AES-GCM optimization for x86_64 architectures
>> supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES
>> and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
On Wed, 14 Jul 2021 10:06:59 GMT, Sibabrata Sahoo wrote:
> Few more Test cases added to verify MessageDigest instance generated through
> different providers.
Marked as reviewed by valeriep (Reviewer).
test/jdk/sun/security/pkcs11/MessageDigest/ReinitDigest.java line 105:
> 103: t
On Tue, 29 Jun 2021 00:07:41 GMT, Sean Coffey wrote:
>> Sufficient permissions missing if this code was ever to run with
>> SecurityManager.
>>
>> Cleanest approach appears to be use of InnocuousThread to create the
>> cleaner/poller threads.
>> Test case coverage extended to cover the Securi
On Tue, 22 Jun 2021 20:08:03 GMT, Sean Coffey wrote:
>> Sufficient permissions missing if this code was ever to run with
>> SecurityManager.
>>
>> Cleanest approach appears to be use of InnocuousThread to create the
>> cleaner/poller threads.
>> Test case coverage extended to cover the Securi
On Fri, 25 Jun 2021 19:39:22 GMT, Valerie Peng wrote:
>> Sean Coffey has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Move TokenPoller to Runnable
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkc
On Tue, 22 Jun 2021 20:08:03 GMT, Sean Coffey wrote:
>> Sufficient permissions missing if this code was ever to run with
>> SecurityManager.
>>
>> Cleanest approach appears to be use of InnocuousThread to create the
>> cleaner/poller threads.
>> Test case coverage extended to cover the Securi
On Wed, 23 Jun 2021 07:38:37 GMT, Aleksey Shipilev wrote:
> SonarCloud reports:
> "Remove or correct this useless self-assignment."
>
>
> if (cipherAlgo.equals("AES")) {
> this.keysize = keysize; // < here
> switch (keysize) {
> case 128:
>
On Tue, 15 Jun 2021 22:37:29 GMT, Valerie Peng wrote:
> Could someone please help review this trivial fix? The real changes are the
> two PKCS11 cipher impl classes under
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/. The rest of
> classes are just cleanups, e.g.
On Wed, 16 Jun 2021 18:10:05 GMT, Valerie Peng wrote:
>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java
>> line 365:
>>
>>> 363: default:
>>> 364: // should never happen; checked by Cipher.init(
On Wed, 16 Jun 2021 17:44:13 GMT, Xue-Lei Andrew Fan wrote:
>> Could someone please help review this trivial fix? The real changes are the
>> two PKCS11 cipher impl classes under
>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/. The rest of
>> classes are just cleanups, e.g. dead
Could someone please help review this trivial fix? The real changes are the two
PKCS11 cipher impl classes under
src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/. The rest of classes
are just cleanups, e.g. dead code or unused code. The
test/jdk/javax/crypto/Cipher/TestCipherMode.java
On Sat, 12 Jun 2021 05:45:35 GMT, Valerie Peng wrote:
> Could someone help review this small fix? This clears the static
> aliasOidsTable field in AlgorithmId class when provider list is changed.
> Enhanced existing regression test to cover the provider removal scenario.
>
> Th
On Fri, 11 Jun 2021 21:22:49 GMT, Valerie Peng wrote:
> Could someone help review this straightforward fix? The current impl for AES
> KW and KWP cipher should check for possible null iv value in its
> CipherSpi.engineGetIV() and CipherSpi.engineGetParameters() impls. Updated
> th
Could someone help review this small fix? This clears the static aliasOidsTable
field in AlgorithmId class when provider list is changed. Enhanced existing
regression test to cover the provider removal scenario.
Thanks,
Valerie
-
Commit messages:
- 8267397: AlgorithmId's OID cache
Could someone help review this straightforward fix? The current impl for AES KW
and KWP cipher should check for possible null iv value in its
CipherSpi.engineGetIV() and CipherSpi.engineGetParameters() impls. Updated the
regression test to cover this scenario as well as some other minor updates.
On Thu, 10 Jun 2021 20:04:13 GMT, Weijun Wang wrote:
>> Remove newly leaked memory.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> clean up one class
Update looks good.
-
Marked as reviewed by valeriep (Revie
On Thu, 10 Jun 2021 17:10:22 GMT, Weijun Wang wrote:
> Remove newly leaked memory.
Marked as reviewed by valeriep (Reviewer).
Changes look good to me. Thanks for catching these.
Valerie
-
PR: https://git.openjdk.java.net/jdk17/pull/3
On Fri, 4 Jun 2021 01:29:36 GMT, Anthony Scarpino wrote:
>> engine is one time use per encryption/decryption. But 'originalOut' is for
>> overlap detection/protection which may be used multiple times during
>> multi-part encryption/decrypion. For each overlapDetection()/restoreOut()
>> pair, t
On Fri, 4 Jun 2021 00:16:55 GMT, Anthony Scarpino wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java
>> line 776:
>>
>>> 774: if (dst != null) {
>>> 775: dst.put(block, 0, len);
>>> 776:
On Thu, 3 Jun 2021 16:04:19 GMT, Anthony Scarpino wrote:
>> Hi,
>>
>> I need a review of this rather large change to GCM. GCM will no longer use
>> CipherCore, and AESCrypt to handle it's buffers and other objects. It is
>> also a major code redesign limits the amount of data copies and mak
On Wed, 2 Jun 2021 03:18:49 GMT, Anthony Scarpino wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java
>> line 942:
>>
>>> 940:
>>> 941: System.arraycopy(out, originalOutOfs, originalOut,
>>> originalOutOfs,
>>> 942: len);
>>
>> Don
On Thu, 3 Jun 2021 16:04:19 GMT, Anthony Scarpino wrote:
>> Hi,
>>
>> I need a review of this rather large change to GCM. GCM will no longer use
>> CipherCore, and AESCrypt to handle it's buffers and other objects. It is
>> also a major code redesign limits the amount of data copies and mak
On Thu, 3 Jun 2021 20:45:41 GMT, Anthony Scarpino wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java
>> line 84:
>>
>>> 82: private static final int MAX_BUF_SIZE = Integer.MAX_VALUE;
>>> 83: // data size when buffer is divided up to aid in intrinsics
>>
On Wed, 2 Jun 2021 20:23:38 GMT, Anthony Scarpino wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java
>> line 1610:
>>
>>> 1608: // update the input parameters for what was taken
>>> out of 'in'
>>> 1609: inOfs += inUsed;
On Thu, 3 Jun 2021 16:04:19 GMT, Anthony Scarpino wrote:
>> Hi,
>>
>> I need a review of this rather large change to GCM. GCM will no longer use
>> CipherCore, and AESCrypt to handle it's buffers and other objects. It is
>> also a major code redesign limits the amount of data copies and mak
On Thu, 4 Feb 2021 10:51:12 GMT, Valerie Peng wrote:
> This change updates SunJCE provider as below:
> - updated existing AESWrap support with AES/KW/NoPadding cipher
> transformation.
> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding.
>
> Existing
On Wed, 2 Jun 2021 03:26:03 GMT, Anthony Scarpino wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java
>> line 975:
>>
>>> 973: doUpdate(in, inOff, inLen, output, 0);
>>> 974: } catch (ShortBufferException e) {
>>> 975:
On Wed, 2 Jun 2021 01:53:51 GMT, Anthony Scarpino wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java
>> line 741:
>>
>>> 739: } else {
>>> 740: // If the remaining in buffer + data does
>>> not fill a
>>> 741
On Wed, 2 Jun 2021 17:52:07 GMT, Valerie Peng wrote:
>> This change updates SunJCE provider as below:
>> - updated existing AESWrap support with AES/KW/NoPadding cipher
>> transformation.
>> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding.
>>
yWrapPadded will do the crypto
> operation over the same input buffer which is allocated and managed by
> KeyWrapCipher class.
>
> Also note that existing AESWrap impl does not take IV. However, the
> corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to
> both
On Fri, 28 May 2021 14:31:25 GMT, Sean Coffey wrote:
>> Added capability to allow the PKCS11 Token to be destroyed once a session is
>> logged out from. New configuration properties via pkcs11 config file.
>> Cleaned up the native resource poller also.
>>
>> New unit test case to test behaviou
On Sun, 30 May 2021 07:25:54 GMT, Valerie Peng wrote:
>> This change updates SunJCE provider as below:
>> - updated existing AESWrap support with AES/KW/NoPadding cipher
>> transformation.
>> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding.
>>
On Mon, 24 May 2021 22:36:49 GMT, Anthony Scarpino
wrote:
>> test/jdk/com/sun/crypto/provider/Cipher/AEAD/GCMShortBuffer.java line 34:
>>
>>> 32: /*
>>> 33: * @test
>>> 34: * @summary Call decrypt doFinal() with different output values to see
>>> if the
>>
>> Missing bug id?
>
> Here is my
On Thu, 20 May 2021 00:57:42 GMT, Valerie Peng wrote:
>> Anthony Scarpino has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix perf problem by reorganizing doLastBlock()
>
> src/java.base/share/c
On Fri, 21 May 2021 04:15:44 GMT, Anthony Scarpino
wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java
>> line 628:
>>
>>> 626: }
>>> 627:
>>> 628: int mergeBlock(byte[] buffer, int bufOfs, byte[] in, int inOfs,
>>
>> Can be made 'static'? No
On Fri, 21 May 2021 03:07:15 GMT, Anthony Scarpino
wrote:
>> yeah these checks are a bit all over the place.. I'll rework them
>
> So I think I only need to add a check to the engineDoFinal() that did not
> have a check before.
for engineUpdate(...) impl, the ArrayUtil.nullAndBoundsCheck() cal
On Mon, 24 May 2021 16:37:05 GMT, Anthony Scarpino
wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/GHASH.java line 189:
>>
>>> 187: ct.position(ct.position());
>>> 188: return processed;
>>> 189: } else if (!ct.isReadOnly()) {
>>
>> Maybe you meant
On Wed, 26 May 2021 21:13:56 GMT, Anthony Scarpino
wrote:
>> Hi,
>>
>> I need a review of this rather large change to GCM. GCM will no longer use
>> CipherCore, and AESCrypt to handle it's buffers and other objects. It is
>> also a major code redesign limits the amount of data copies and m
yWrapPadded will do the crypto
> operation over the same input buffer which is allocated and managed by
> KeyWrapCipher class.
>
> Also note that existing AESWrap impl does not take IV. However, the
> corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to
> both
On Tue, 25 May 2021 20:33:55 GMT, Valerie Peng wrote:
>> This change updates SunJCE provider as below:
>> - updated existing AESWrap support with AES/KW/NoPadding cipher
>> transformation.
>> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding.
>>
yWrapPadded will do the crypto
> operation over the same input buffer which is allocated and managed by
> KeyWrapCipher class.
>
> Also note that existing AESWrap impl does not take IV. However, the
> corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to
> both
On Fri, 14 May 2021 00:33:12 GMT, Valerie Peng wrote:
>> This change updates SunJCE provider as below:
>> - updated existing AESWrap support with AES/KW/NoPadding cipher
>> transformation.
>> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding.
>>
On Sat, 22 May 2021 01:02:50 GMT, Xue-Lei Andrew Fan wrote:
>> Valerie Peng has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains seven commits:
>>
>> - Merge master into JDK-8248268
>> - Minor upd
On Sat, 22 May 2021 00:45:27 GMT, Xue-Lei Andrew Fan wrote:
>> Valerie Peng has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains seven commits:
>>
>> - Merge master into JDK-8248268
>> - Minor upd
On Fri, 21 May 2021 20:44:57 GMT, Xue-Lei Andrew Fan wrote:
>> Valerie Peng has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains seven commits:
>>
>> - Merge master into JDK-8248268
>> - Minor upd
On Fri, 21 May 2021 19:15:49 GMT, Xue-Lei Andrew Fan wrote:
>> Valerie Peng has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains seven commits:
>>
>> - Merge master into JDK-8248268
>> - Minor upd
On Fri, 21 May 2021 21:18:34 GMT, Anthony Scarpino
wrote:
>> Hi,
>>
>> I need a review of this rather large change to GCM. GCM will no longer use
>> CipherCore, and AESCrypt to handle it's buffers and other objects. It is
>> also a major code redesign limits the amount of data copies and m
On Fri, 21 May 2021 04:07:05 GMT, Anthony Scarpino
wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java
>> line 640:
>>
>>> 638: * @return number of bytes used from 'in'
>>> 639: */
>>> 640: int mergeBlock(byte[] buffer, int bufOfs, int
On Mon, 24 May 2021 16:54:39 GMT, Anthony Scarpino
wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/GHASH.java line 338:
>>
>>> 336: public int doFinal(ByteBuffer src, ByteBuffer dst) {
>>> 337: return doFinal(src, src.remaining());
>>> 338: }
>>
>> Have you consid
On Mon, 24 May 2021 16:34:51 GMT, Anthony Scarpino
wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/GCTR.java line 203:
>>
>>> 201: // allocating and copying for direct bytebuffers
>>> 202: if (!src.isDirect() && !dst.isDirect() &&
>>> 203: !src.isReadOn
On Wed, 19 May 2021 20:21:23 GMT, Anthony Scarpino
wrote:
>> Hi,
>>
>> I need a review of this rather large change to GCM. GCM will no longer use
>> CipherCore, and AESCrypt to handle it's buffers and other objects. It is
>> also a major code redesign limits the amount of data copies and m
On Mon, 17 May 2021 21:58:48 GMT, Valerie Peng wrote:
>> Anthony Scarpino has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - review comment updates
>> - Fixed the lack of overlap detection with GCMEncr
On Wed, 19 May 2021 20:21:23 GMT, Anthony Scarpino
wrote:
>> Hi,
>>
>> I need a review of this rather large change to GCM. GCM will no longer use
>> CipherCore, and AESCrypt to handle it's buffers and other objects. It is
>> also a major code redesign limits the amount of data copies and m
On Tue, 18 May 2021 03:18:18 GMT, Anthony Scarpino
wrote:
>> Hi,
>>
>> I need a review of this rather large change to GCM. GCM will no longer use
>> CipherCore, and AESCrypt to handle it's buffers and other objects. It is
>> also a major code redesign limits the amount of data copies and m
On Mon, 17 May 2021 21:41:37 GMT, Anthony Scarpino
wrote:
>> Hi,
>>
>> I need a review of this rather large change to GCM. GCM will no longer use
>> CipherCore, and AESCrypt to handle it's buffers and other objects. It is
>> also a major code redesign limits the amount of data copies and m
On Tue, 18 May 2021 04:03:16 GMT, Martin Balao wrote:
>> Hi,
>>
>> Please find in this PR a proposal to fix JDK-8265462 [1].
>>
>> With this fix, OpenJDK will only use the known slot IDs for the NSS Internal
>> Module. If the NSS Internal Module has more slots (for example, as a result
>> of
On Mon, 17 May 2021 20:24:51 GMT, Valerie Peng wrote:
>> Hi,
>>
>> I need a review of this rather large change to GCM. GCM will no longer use
>> CipherCore, and AESCrypt to handle it's buffers and other objects. It is
>> also a major code redesign limits
On Mon, 17 May 2021 18:13:46 GMT, Anthony Scarpino
wrote:
> Hi,
>
> I need a review of this rather large change to GCM. GCM will no longer use
> CipherCore, and AESCrypt to handle it's buffers and other objects. It is
> also a major code redesign limits the amount of data copies and make s
On Mon, 17 May 2021 18:13:46 GMT, Anthony Scarpino
wrote:
> Hi,
>
> I need a review of this rather large change to GCM. GCM will no longer use
> CipherCore, and AESCrypt to handle it's buffers and other objects. It is
> also a major code redesign limits the amount of data copies and make s
On Tue, 27 Apr 2021 02:41:12 GMT, Valerie Peng wrote:
> Anyone can help review this somewhat trivial fix? The main change is inside
> src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c. This is to
> help better troubleshooting by reporting the type of unavailable attribu
tributeValue(...) call failed. The
> java file changes are just cleanup for consolidating the CKR_* constants
> definition into PKCS11Exception class.
>
> Thanks,
> Valerie
Valerie Peng has updated the pull request incrementally with one additional
commit since the last revision:
On Fri, 14 May 2021 00:15:09 GMT, Xue-Lei Andrew Fan wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> PKCS11Exception class refactoring - use enum instead of HashMap
>
> src/jdk.cry
yWrapPadded will do the crypto
> operation over the same input buffer which is allocated and managed by
> KeyWrapCipher class.
>
> Also note that existing AESWrap impl does not take IV. However, the
> corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to
> both
tributeValue(...) call failed. The
> java file changes are just cleanup for consolidating the CKR_* constants
> definition into PKCS11Exception class.
>
> Thanks,
> Valerie
Valerie Peng has updated the pull request incrementally with one additional
commit since the last revisio
yWrapPadded will do the crypto
> operation over the same input buffer which is allocated and managed by
> KeyWrapCipher class.
>
> Also note that existing AESWrap impl does not take IV. However, the
> corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to
> both
tributeValue(...) call failed. The
> java file changes are just cleanup for consolidating the CKR_* constants
> definition into PKCS11Exception class.
>
> Thanks,
> Valerie
Valerie Peng has updated the pull request incrementally with one additional
commit since the last revision:
Fix
On Fri, 7 May 2021 13:51:05 GMT, Sean Coffey wrote:
>> Added capability to allow the PKCS11 Token to be destroyed once a session is
>> logged out from. New configuration properties via pkcs11 config file.
>> Cleaned up the native resource poller also.
>>
>> New unit test case to test behaviour
On Thu, 6 May 2021 14:25:13 GMT, Weijun Wang wrote:
>> `PKCS12KeyStore` always uses a 20-byte salt in encryption but
>> PBEWithMD5AndDES only accepts 8-byte salt. With this code change, the salt
>> used for this algorithm will be 8 bytes.
>>
>> RFC 2898 only requires the salt to be at least 8
On Fri, 30 Apr 2021 17:35:46 GMT, Weijun Wang wrote:
> `PKCS12KeyStore` always uses a 20-byte salt in encryption but
> PBEWithMD5AndDES only accepts 8-byte salt. With this code change, the salt
> used for this algorithm will be 8 bytes.
>
> RFC 2898 only requires the salt to be at least 8 byte
On Fri, 30 Apr 2021 17:35:46 GMT, Weijun Wang wrote:
> `PKCS12KeyStore` always uses a 20-byte salt in encryption but
> PBEWithMD5AndDES only accepts 8-byte salt. With this code change, the salt
> used for this algorithm will be 8 bytes.
>
> RFC 2898 only requires the salt to be at least 8 byte
On Fri, 23 Apr 2021 19:32:35 GMT, Martin Balao wrote:
> Hi,
>
> Please find in this PR a proposal to fix JDK-8265462 [1].
>
> With this fix, OpenJDK will only use the known slot IDs for the NSS Internal
> Module. If the NSS Internal Module has more slots (for example, as a result
> of an init
On Fri, 23 Apr 2021 19:32:35 GMT, Martin Balao wrote:
> Hi,
>
> Please find in this PR a proposal to fix JDK-8265462 [1].
>
> With this fix, OpenJDK will only use the known slot IDs for the NSS Internal
> Module. If the NSS Internal Module has more slots (for example, as a result
> of an init
On Fri, 23 Apr 2021 19:32:35 GMT, Martin Balao wrote:
> Hi,
>
> Please find in this PR a proposal to fix JDK-8265462 [1].
>
> With this fix, OpenJDK will only use the known slot IDs for the NSS Internal
> Module. If the NSS Internal Module has more slots (for example, as a result
> of an init
On Fri, 16 Apr 2021 11:24:57 GMT, Sean Coffey wrote:
> Added capability to allow the PKCS11 Token to be destroyed once a session is
> logged out from. New configuration properties via pkcs11 config file. Cleaned
> up the native resource poller also.
>
> New unit test case to test behaviour. So
On Fri, 16 Apr 2021 11:24:57 GMT, Sean Coffey wrote:
> Added capability to allow the PKCS11 Token to be destroyed once a session is
> logged out from. New configuration properties via pkcs11 config file. Cleaned
> up the native resource poller also.
>
> New unit test case to test behaviour. So
On Fri, 16 Apr 2021 11:24:57 GMT, Sean Coffey wrote:
> Added capability to allow the PKCS11 Token to be destroyed once a session is
> logged out from. New configuration properties via pkcs11 config file. Cleaned
> up the native resource poller also.
>
> New unit test case to test behaviour. So
On Tue, 27 Apr 2021 18:46:21 GMT, Greg Rubin
wrote:
>> For this particular call, the pValue field is null, it's meant to query the
>> exact length of the specified attribute. Thus, CKR_BUFFER_TOO_SMALL should
>> not be returned.
>> Afterwards, we then allocate the buffer based on this queried
On Fri, 9 Apr 2021 17:08:30 GMT, Valerie Peng wrote:
> Could someone (perhaps Jamil?) please help review this change? This enhances
> SunPKCS11 provider with ChaCha20-Poly1305 cipher and ChaCha20 key generation
> support. Majority of the regression tests are adapted from the exis
On Tue, 27 Apr 2021 18:49:30 GMT, Valerie Peng wrote:
>> src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c line 189:
>>
>>> 187: * returnValue is CKR_OK. Otherwise, it returns the returnValue as a
>>> jLong.
>>> 188: *
>>> 189: * @p
On Tue, 27 Apr 2021 15:13:10 GMT, Greg Rubin
wrote:
>> src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c line 262:
>>
>>> 260: temp1 = msg;
>>> 261: temp2 = msg + 80;
>>> 262: for (i = 0; i < ckAttributesLength && temp1 < temp2; i++) {
>>
>> I t
On Tue, 27 Apr 2021 04:27:10 GMT, Greg Rubin
wrote:
>> Anyone can help review this somewhat trivial fix? The main change is inside
>> src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c. This is to
>> help better troubleshooting by reporting the type of unavailable attributes
>> in
On Tue, 27 Apr 2021 04:31:42 GMT, Greg Rubin
wrote:
>> Anyone can help review this somewhat trivial fix? The main change is inside
>> src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c. This is to
>> help better troubleshooting by reporting the type of unavailable attributes
>> in
On Tue, 27 Apr 2021 08:13:03 GMT, Sibabrata Sahoo wrote:
>> This is a simple Test to add few additional API coverage for all java
>> supported key types. The objective of this Test is to cover equals() and
>> hashcode() methods for each key types.
>
> Sibabrata Sahoo has updated the pull reques
On Fri, 16 Apr 2021 11:24:57 GMT, Sean Coffey wrote:
> Added capability to allow the PKCS11 Token to be destroyed once a session is
> logged out from. New configuration properties via pkcs11 config file. Cleaned
> up the native resource poller also.
>
> New unit test case to test behaviour. So
Anyone can help review this somewhat trivial fix? The main change is inside
src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c. This is to help
better troubleshooting by reporting the type of unavailable attributes in
PKCS11 exception message when C_GetAttributeValue(...) call failed
301 - 400 of 1381 matches
Mail list logo
