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.
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 toke
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
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 arra
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
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 la
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
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
includ
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
