Re: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider

[Martin Balao]

Hi,

That's correct: TestTLS12.java was introduced by this patch and is checking
that the new feature (TLS 1.2 + SunPKCS11) is working correctly. If the
PKCS11 library does not support TLS 1.2 mechanisms, the test must fail.
This test should be skipped on those configurations.

Kind regards,
Martin.-

On Thu, Jul 26, 2018 at 7:44 PM, Valerie Peng 
wrote:

>
> Update: I submitted your webrev.05 through Mach5, there are one test
> failure observed on 4 configurations, all are due to the regression test
> TestTLS12.java. It looks like the test fails when the underlying PKCS11
> library does not support the corresponding TLS 12 mechanisms (stacktrace
> included as below)
>
> jib > STDERR:
> jib > java.security.ProviderException: Could not generate key
> jib > at 
> jdk.crypto.cryptoki/sun.security.pkcs11.P11TlsMasterSecretGenerator.engineGenerateKey(P11TlsMasterSecretGenerator.java:181)
> jib > at 
> java.base/javax.crypto.KeyGenerator.generateKey(KeyGenerator.java:563)
> jib > at 
> TestTLS12.testTlsAuthenticationCodeGeneration(TestTLS12.java:181)
> jib > at TestTLS12.main(TestTLS12.java:104)
> jib > at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> jib > at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> jib > at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> jib > at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> jib > at 
> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115)
> jib > at java.base/java.lang.Thread.run(Thread.java:834)
> jib > Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: 
> CKR_MECHANISM_INVALID
> jib > at 
> jdk.crypto.cryptoki/sun.security.pkcs11.wrapper.PKCS11.C_DeriveKey(Native 
> Method)
> jib > at 
> jdk.crypto.cryptoki/sun.security.pkcs11.P11TlsMasterSecretGenerator.engineGenerateKey(P11TlsMasterSecretGenerator.java:167)
> jib > ... 9 more
> jib >
> jib > JavaTest Message: Test threw exception: 
> java.security.ProviderException: Could not generate key
> jib > JavaTest Message: shutting down test
> jib >
> jib > STATUS:Failed.`main' threw exception: java.security.ProviderException: 
> Could not generate key
>
> Thanks,
> Valerie
>
>
> On 7/23/2018 9:50 PM, Martin Balao wrote:
>
> Hi Valerie,
>
> Webrev 05:
>
>  * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.05/
>  * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/
> 8029661.webrev.05.zip
>
> New in Webrev 05:
>
>  * Explicitly casted prfHashMechanism to CK_MECHANISM_TYPE type to avoid
> building warning on some compilers (it's a long -> unsigned long cast).
>
> Regression tests result for jdk/sun/security/pkcs11 category:
>
> Passed: sun/security/pkcs11/Cipher/JNICheck.java
> Passed: sun/security/pkcs11/Cipher/ReinitCipher.java
> Passed: sun/security/pkcs11/Cipher/TestPKCS5PaddingError.java
> Passed: sun/security/pkcs11/Cipher/TestRawRSACipher.java
> Passed: sun/security/pkcs11/Cipher/TestRSACipher.java
> Passed: sun/security/pkcs11/Cipher/TestRSACipherWrap.java
> Passed: sun/security/pkcs11/Cipher/TestSymmCiphers.java
> Passed: sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java
> Passed: sun/security/pkcs11/Config/ReadConfInUTF16Env.sh
> Passed: sun/security/pkcs11/ec/ReadCertificates.java
> Passed: sun/security/pkcs11/ec/ReadPKCS12.java
> Passed: sun/security/pkcs11/ec/TestCurves.java
> Passed: sun/security/pkcs11/ec/TestECDH.java
> Passed: sun/security/pkcs11/ec/TestECDH2.java
> Passed: sun/security/pkcs11/ec/TestECDSA.java
> Passed: sun/security/pkcs11/ec/TestECDSA2.java
> Passed: sun/security/pkcs11/ec/TestECGenSpec.java
> FAILED: sun/security/pkcs11/ec/TestKeyFactory.java
> Passed: sun/security/pkcs11/fips/ClientJSSEServerJSSE.java
> Passed: sun/security/pkcs11/fips/TrustManagerTest.java
> Passed: sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java
> Passed: sun/security/pkcs11/KeyAgreement/TestDH.java
> Passed: sun/security/pkcs11/KeyAgreement/TestInterop.java
> Passed: sun/security/pkcs11/KeyAgreement/TestShort.java
> Passed: sun/security/pkcs11/KeyAgreement/UnsupportedDHKeys.java
> Passed: sun/security/pkcs11/KeyGenerator/DESParity.java
> Passed: sun/security/pkcs11/KeyGenerator/TestKeyGenerator.java
> Passed: sun/security/pkcs11/KeyPairGenerator/TestDH2048.java
> Passed: sun/security/pkcs11/KeyStore/Basic.sh
> Passed: sun/security/pkcs11/KeyStore/ClientAuth.sh
> Passed: sun/security/pkcs11/KeyStore/SecretKeysBasic.sh
> Passed: sun/security/pkcs11/KeyStore/Solaris.sh
> Passed: sun/security/pkcs11/Mac/MacKAT.java
> Passed: sun/security/pkcs11/Mac/MacSameTest.java
> Passed: sun/security/pkcs11/Mac/ReinitMac.java
> Passed: sun/security/pkcs11/MessageDigest/ByteBuffers.java
> Passed: sun/security/pkcs11/MessageDigest/DigestKAT.java
> Passed: sun/security/pkcs11/MessageDigest/ReinitDigest.java
> 

Re: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider

[Valerie Peng]

Update: I submitted your webrev.05 through Mach5, there are one test 
failure observed on 4 configurations, all are due to the regression test 
TestTLS12.java. It looks like the test fails when the underlying PKCS11 
library does not support the corresponding TLS 12 mechanisms (stacktrace 
included as below)


jib > STDERR:
jib > java.security.ProviderException: Could not generate key
jib >at 
jdk.crypto.cryptoki/sun.security.pkcs11.P11TlsMasterSecretGenerator.engineGenerateKey(P11TlsMasterSecretGenerator.java:181)
jib >at 
java.base/javax.crypto.KeyGenerator.generateKey(KeyGenerator.java:563)
jib >at 
TestTLS12.testTlsAuthenticationCodeGeneration(TestTLS12.java:181)
jib >at TestTLS12.main(TestTLS12.java:104)
jib >at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
jib >at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
jib >at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
jib >at java.base/java.lang.reflect.Method.invoke(Method.java:566)
jib >at 
com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115)
jib >at java.base/java.lang.Thread.run(Thread.java:834)
jib > Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: 
CKR_MECHANISM_INVALID
jib >at 
jdk.crypto.cryptoki/sun.security.pkcs11.wrapper.PKCS11.C_DeriveKey(Native Method)
jib >at 
jdk.crypto.cryptoki/sun.security.pkcs11.P11TlsMasterSecretGenerator.engineGenerateKey(P11TlsMasterSecretGenerator.java:167)
jib >... 9 more
jib >
jib > JavaTest Message: Test threw exception: java.security.ProviderException: 
Could not generate key
jib > JavaTest Message: shutting down test
jib >
jib > STATUS:Failed.`main' threw exception: java.security.ProviderException: 
Could not generate key

Thanks,
Valerie

On 7/23/2018 9:50 PM, Martin Balao wrote:

Hi Valerie,

Webrev 05:

 * 
http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.05/ 

 * 
http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.05.zip 



New in Webrev 05:

 * Explicitly casted prfHashMechanism to CK_MECHANISM_TYPE type to 
avoid building warning on some compilers (it's a long -> unsigned long 
cast).


Regression tests result for jdk/sun/security/pkcs11 category:

Passed: sun/security/pkcs11/Cipher/JNICheck.java
Passed: sun/security/pkcs11/Cipher/ReinitCipher.java
Passed: sun/security/pkcs11/Cipher/TestPKCS5PaddingError.java
Passed: sun/security/pkcs11/Cipher/TestRawRSACipher.java
Passed: sun/security/pkcs11/Cipher/TestRSACipher.java
Passed: sun/security/pkcs11/Cipher/TestRSACipherWrap.java
Passed: sun/security/pkcs11/Cipher/TestSymmCiphers.java
Passed: sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java
Passed: sun/security/pkcs11/Config/ReadConfInUTF16Env.sh
Passed: sun/security/pkcs11/ec/ReadCertificates.java
Passed: sun/security/pkcs11/ec/ReadPKCS12.java
Passed: sun/security/pkcs11/ec/TestCurves.java
Passed: sun/security/pkcs11/ec/TestECDH.java
Passed: sun/security/pkcs11/ec/TestECDH2.java
Passed: sun/security/pkcs11/ec/TestECDSA.java
Passed: sun/security/pkcs11/ec/TestECDSA2.java
Passed: sun/security/pkcs11/ec/TestECGenSpec.java
FAILED: sun/security/pkcs11/ec/TestKeyFactory.java
Passed: sun/security/pkcs11/fips/ClientJSSEServerJSSE.java
Passed: sun/security/pkcs11/fips/TrustManagerTest.java
Passed: sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java
Passed: sun/security/pkcs11/KeyAgreement/TestDH.java
Passed: sun/security/pkcs11/KeyAgreement/TestInterop.java
Passed: sun/security/pkcs11/KeyAgreement/TestShort.java
Passed: sun/security/pkcs11/KeyAgreement/UnsupportedDHKeys.java
Passed: sun/security/pkcs11/KeyGenerator/DESParity.java
Passed: sun/security/pkcs11/KeyGenerator/TestKeyGenerator.java
Passed: sun/security/pkcs11/KeyPairGenerator/TestDH2048.java
Passed: sun/security/pkcs11/KeyStore/Basic.sh
Passed: sun/security/pkcs11/KeyStore/ClientAuth.sh
Passed: sun/security/pkcs11/KeyStore/SecretKeysBasic.sh
Passed: sun/security/pkcs11/KeyStore/Solaris.sh
Passed: sun/security/pkcs11/Mac/MacKAT.java
Passed: sun/security/pkcs11/Mac/MacSameTest.java
Passed: sun/security/pkcs11/Mac/ReinitMac.java
Passed: sun/security/pkcs11/MessageDigest/ByteBuffers.java
Passed: sun/security/pkcs11/MessageDigest/DigestKAT.java
Passed: sun/security/pkcs11/MessageDigest/ReinitDigest.java
Passed: sun/security/pkcs11/MessageDigest/TestCloning.java
Passed: sun/security/pkcs11/Provider/Absolute.java
Passed: sun/security/pkcs11/Provider/ConfigQuotedString.sh
Passed: sun/security/pkcs11/Provider/ConfigShortPath.java
Passed: sun/security/pkcs11/Provider/Login.sh
Passed: sun/security/pkcs11/Provider/LoginISE.java
Passed: sun/security/pkcs11/rsa/KeyWrap.java
Passed: 

Re: Please review EdDSA API

[Adam Petcher]

On 7/26/2018 5:05 PM, Michael StJohns wrote:

The test vectors will not pass, because they are calling the byte 
array from which the private key and the signing value are derived as 
the private key.


However, each and every signature generated by the above approach 
(e.g. using a *real* private key and a signing value downstream 
derived from that private key) *will* verify, and each and every 
signature by that private key over the same data using the above 
approach will produce identical signatures.




I've stated in the JEP[1] that the goal of this effort is an 
implementation of EdDSA as described in the RFC. What you are proposing 
is a slightly different key generation and signing procedure. The fact 
that the signatures will still verify is not sufficient to convince me 
that the procedures that you are proposing offer the same security as 
the ones in the RFC.


I understand that you don't like the fact that I am representing the 
private key value as a byte array instead of an integer. If you can come 
up with an alternative representation that still allows the same 
functions that are specified in the RFC, then I will consider it.



[1] https://bugs.openjdk.java.net/browse/JDK-8199231

Re: Please review EdDSA API

[Michael StJohns]

On 7/26/2018 4:24 PM, Adam Petcher wrote:

On 7/26/2018 3:58 PM, Michael StJohns wrote:


On 7/25/2018 2:05 PM, Adam Petcher wrote:


Did you mean PrivateKey ::= OctetToInteger(random)? Setting/clearing 
bits here destroys information. If we don't prune here, then we can 
reverse this operation later to get the byte array back to give to 
the hash.


No - I meant what I wrote:

1) generate a private key from a random and store it as a big 
integer.  E.g. generate a byte array of the appropriate length (32), 
twiddle the bits as described in step 2 of section 5.1.5 of RFC8032 
and - interpreting that buffer as a little-endian encoding, save 's' 
(the secret scalar - aka - the actual private key) as a BigInteger.


That's the limit of what goes into the PrivateKey spec/interface.
2) When you do a signing, do SigningValue = 
HASH(IntegerToLittleEndianOctets(s)).
3) When done with signing, throw away the hash value - it doesn't 
need to be stored.


Does this produce the same result as the signing function described in 
sections 3.2 and 3.3 of the RFC? If I do as you suggest, will the test 
vectors in Section 7 pass? It's not obvious to me that the signing 
procedure that you are proposing is the same function.


Note that the signing value (e.g. prefix) is used as part of the 
formation of 'r' in signing, but is not recoverable from the 
signature.   s is calculated from whatever value of r you get and the 
two taken together (r,s) form the actual signature.   Note that 'prefix' 
could be a random value if you wanted non-deterministic signatures, but 
the inclusion of a fixed prefix value means that the same signature will 
be generated by the same private key over the same data.


The test vectors will not pass, because they are calling the byte array 
from which the private key and the signing value are derived as the 
private key.


However, each and every signature generated by the above approach (e.g. 
using a *real* private key and a signing value downstream derived from 
that private key) *will* verify, and each and every signature by that 
private key over the same data using the above approach will produce 
identical signatures.


Mike

Re: Please review EdDSA API

[Adam Petcher]

On 7/26/2018 3:58 PM, Michael StJohns wrote:


On 7/25/2018 2:05 PM, Adam Petcher wrote:


Did you mean PrivateKey ::= OctetToInteger(random)? Setting/clearing 
bits here destroys information. If we don't prune here, then we can 
reverse this operation later to get the byte array back to give to 
the hash.


No - I meant what I wrote:

1) generate a private key from a random and store it as a big 
integer.  E.g. generate a byte array of the appropriate length (32), 
twiddle the bits as described in step 2 of section 5.1.5 of RFC8032 
and - interpreting that buffer as a little-endian encoding, save 's' 
(the secret scalar - aka - the actual private key) as a BigInteger.


That's the limit of what goes into the PrivateKey spec/interface.
2) When you do a signing, do SigningValue = 
HASH(IntegerToLittleEndianOctets(s)).
3) When done with signing, throw away the hash value - it doesn't need 
to be stored.


Does this produce the same result as the signing function described in 
sections 3.2 and 3.3 of the RFC? If I do as you suggest, will the test 
vectors in Section 7 pass? It's not obvious to me that the signing 
procedure that you are proposing is the same function.

Re: Please review EdDSA API

[Michael StJohns]

On 7/25/2018 2:05 PM, Adam Petcher wrote:

On 7/25/2018 11:24 AM, Michael StJohns wrote:



*sigh* Private keys are big integers.  There's an associated 
parameter used in signing that the implementation described in the 
RFC (*not a standard please note*) generates from a common random 
byte array - that byte array is NOT a (or the) private key.


E.g.   Private key ::= OctetToInteger(Adjust(Left (HASH(random), 
length))) and SigningValue ::= Right(HASH(random),length).


Instead, you can get the exact same result (deterministic signatures) 
- and store a bog standard EC private key - by


PrivateKey ::= OctetToInteger(Adjust(random));


Did you mean PrivateKey ::= OctetToInteger(random)? Setting/clearing 
bits here destroys information. If we don't prune here, then we can 
reverse this operation later to get the byte array back to give to the 
hash.


No - I meant what I wrote:

1) generate a private key from a random and store it as a big integer.  
E.g. generate a byte array of the appropriate length (32), twiddle the 
bits as described in step 2 of section 5.1.5 of RFC8032 and - 
interpreting that buffer as a little-endian encoding, save 's' (the 
secret scalar - aka - the actual private key) as a BigInteger.


That's the limit of what goes into the PrivateKey spec/interface.
2) When you do a signing, do SigningValue = 
HASH(IntegerToLittleEndianOctets(s)).
3) When done with signing, throw away the hash value - it doesn't need 
to be stored.


The *only* important characteristics of the signing value are a) it's 
confidential, and b) it's the same for each signature.  It could even be 
a random value generated and stored at the same time as the private key 
- but why?







SigningValue ::= HASH (IntegerToOctet(PrivateKey)); // signing value 
may be regenerated at any time and need not be stored in the 
ECPrivateKey class.


With the modification above, I agree that this would give the value 
that can be split in half to produce the scalar value (after pruning 
and interpreting as an integer) and the prefix that is used in signing.


I think there may be some issues with this approach, but we need to 
start by agreeing on what you are proposing. Can you confirm that my 
understanding of your proposal is correct, or else clarify it for me?


What I'm trying to get to is make the java interfaces for EC private 
keys consistent regardless of which of the curve flavor you want to 
use.   In each and every case, looking behind the specified external 
representation, the scalar 's' can be represented as a BigInteger. 
Internal representation IN A SPECIFIC IMPLEMENTATION might use little 
endian internally, but that's irrelevant here for the purposes of java 
interfaces.    (At least in my opinion).


Later, Mike

Re: RFR: 8207775: Better management of CipherCore buffers

[Anthony Scarpino]

On 07/26/2018 07:36 AM, Seán Coffey wrote:

https://bugs.openjdk.java.net/browse/JDK-8207775

Simple enough fix to null out some internal buffers once they're no 
longer required.


webrev : http://cr.openjdk.java.net/~coffeys/webrev.8207775/webrev/

regards,
Sean.



that looks fine..

Tony

Re: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider

[Martin Balao]

Hi Valerie,

Thanks for your feedback!

CKM_TLS12_MAC looks like it's not in use. Authentication codes are
calculated through CKM_TLS12_KEY_AND_MAC_DERIVE mechanism. Do you know of a
library supporting CKM_TLS12_MAC but not CKM_TLS12_KEY_AND_MAC_DERIVE? I've
been testing this with NSS software token which does not support
CKM_TLS12_MAC.

module-info.java changes were from when we used SSL/TLS constants, but then
I replaced these constants with hardcoded numbers -after discussing with
Xuelei-. I forgot to revert changes on this file. Thanks.

Config.java changes were from a wrong version I uploaded. This has been
already fixed.

SunPKCS11.java: I agree with you that registration must be done separately.
SunTls12MasterSecret and SunTls12KeyMaterial are now registered separately.
I've added CKM_TLS12_MASTER_KEY_DERIVE_DH mechanism to SunTls12MasterSecret
algorithm. It's still assumed that if CKM_TLS12_MASTER_KEY_DERIVE is
supported, then CKM_TLS12_MASTER_KEY_DERIVE_DH it's and vice-versa -same as
with previous key derivation mechanisms-. Not a big deal though I think:
it's unlikely that a library implements only one of these. Using protocol
version to decide which mechanism to use should be valid in this case
because if an instance of P11TlsMasterSecretGenerator is used and algorithm
is SunTls12MasterSecret, then protocol must be TLS 1.2 and we can assume
that there is support of these mechanisms in the underlying library.
L527: I've realized that a better place for this map is Functions.java.
I've moved it there.

P11TlsPrfGenerator.java: This code is for TLS 1.2 only. That's because
CKM_TLS_MAC mechanism is registered for SunTls12Prf algorithm. Previous TLS
versions use CKM_TLS_PRF and CKM_NSS_TLS_PRF_GENERAL.

P11TlsRsaPremasterSecretGenerator.java: Yes, we can remove it and call all
keys "TlsRsaPremasterSecret", disregarding the mechanism used to generate
it (CKM_SSL3_PRE_MASTER_KEY_GEN or CKM_TLS_PRE_MASTER_KEY_GEN). At the end
of the day, this is just an array of 48 bytes. I've removed the field too.

Functions.java: New entries (CKM_TLS12_MASTER_KEY_DERIVE,
CKM_TLS12_MASTER_KEY_DERIVE_DH and CKM_TLS_MAC) moved after line 721.
CKM_TLS12_KEY_AND_MAC_DERIVE has been added for completeness.

CK_ATTRIBUTE.java: SENSITIVE_TRUE removed.

Removed a dependency in TestTLS12.java to HexDumper (internal).

Webrev 06 with all these changes here:

 * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.06/
 * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.06.zip

Regression testing on jdk/sun/security/pkcs11 passes with samae pass rate.

Kind regards,
Martin.-

On Tue, Jul 24, 2018 at 11:00 PM, Valerie Peng 
wrote:

> Hi Martin,
>
> Sorry for the delay, I am able to resume on reviewing this now.
>
> Here are some initial comments.
>
> What about CKM_TLS12_MAC? I see that it's defined under TLS 1.2
> mechanisms, but not much other details for it.
> 
> - Is this change still necessary? I didn't notice any new import statement
> with sun.security.ssl package in the rest of changes.
>
> 
> - Why removing the SENSITIVE_FALSE attribute on line 829 and 854?
>
> 
> - As my comments for the SunPKCS11.java (see below), I think we should not
> assume the support for CKM_TLS12_KEY_AND_MAC_DERIVE. The existing impl and
> how it's registered in SunPKCS11 class is already somewhat problematic when
> CKM_TLS_KEY_AND_MAC_DERIVE is not supported. We should avoid assuming
> CKM_TLS12_KEY_AND_MAC_DERIVE is supported which may create even more
> problems. Overriding this.mechanism based on the TLS version specified in
> the parameters from the engineInit(...) call will lead to failure when the
> mechanism is not supported by underlying PKCS11 library
>
> 
> - Please see above comments for P11TlsKeyMaterialGenerator.java
>
> 
> - Retrieve label outside of the new code block for TLS 1.2, i.e. line 133-
> 167, as it's used by all mechanisms.
>
> 
> - Line 131, Is it really necessary to use SunTls12RsaPremasterSecret?
> SunJCE provider uses SunTlsRsaPremasterSecret for all cases. If different
> algorithm is not needed, then no need to save tlsVersion as a field
>
> 
> - Hmm, for TLS 12 specific mechanisms, some PKCS11 libraries may not
> support them. Instead of registering SunTls12MasterSecret/SunTls12KeyMaterial
> as aliases, they should be registered separately so that if the native TLS
> 12 mechanisms were not supported, the new entry will be skipped. The
> corresponding implementation classes such as P11TlsMasterSecretGenerator
> and P11TlsKeyMaterialGenerator will have to check the specified parameter
> spec in their engineInit(..) calls to make sure things line up, e.g. error
> out if the TLS version in the spec does not match the native mechanism.
> - Lines 528 - 532, the mapping is stored without checking for support. May
> become an issue when the underlying PKCS11 library does not support all of
> these hash mechanisms. Probably not a big deal as these are fairly common
> hash algorithms, but I 

RFR: 8207775: Better management of CipherCore buffers

[Seán Coffey]

https://bugs.openjdk.java.net/browse/JDK-8207775

Simple enough fix to null out some internal buffers once they're no 
longer required.


webrev : http://cr.openjdk.java.net/~coffeys/webrev.8207775/webrev/

regards,
Sean.

Re: Code Review Request, JDK-8208166, Still unable to use custom SSLEngine with default TrustManagerFactory after JDK-8207029

[Norman Maurer]

Just FYI… I tested this patch via the netty ssl tests and we no longer see the 
class-cast-exception problems I reported before dso I think this solves the 
issue.


That said we still encounter a few test-failures for tests that test behaviour 
of closing outbound of the SSLEngine but I think these are more related to 
http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017633.html 
 and 
http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017566.html 
 .

Bye
Norman



> On 25. Jul 2018, at 20:30, Xuelei Fan  wrote:
> 
> Hi,
> 
> Please review the update for JDK-8208166:
>   http://cr.openjdk.java.net/~xuelei/8208166/webrev.00/
>   https://bugs.openjdk.java.net/browse/JDK-8208166
> 
> Thanks,
> Xuelei