Bug: https://bugs.openjdk.java.net/browse/JDK-8220641
Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8220641/webrev.01/
This is the patch we split out from my original post for 8175120. It
applies the same change to the @run command in KdcPolicy.java as was
applied to the tests deleted by 81
Hello,
yes you are right, in the PBKDF2 case there is no external key object which can
hit the MAC, so this seems safe. Thanks for bearing with me 😊
Ist BTW funny how many people want to use a FIPS compliant library and then not
use the FIPS restrictions 😊 (well actually it is not funny, the F
Hello Bernd, once again I appreciate your comments and have some of my
own in-line,
On 3/14/2019 9:30 AM, Bernd Eckenfels wrote:
Hello,
is there no case where the passed-in key cannot be used by the SunJCE
provider? Isnt that a main reason to use an alternative Provider and
PKCS11 especiall
Hello,
is there no case where the passed-in key cannot be used by the SunJCE provider?
Isnt that a main reason to use an alternative Provider and PKCS11 especially? I
think similiar could be said for MSCAPI (but I think they have no keyhandles
for secret keys) or other FIPS Keystores which do n
Hi Bernd, thanks for the feedback, comments below:
On 3/14/19 8:58 AM, Bernd Eckenfels wrote:
Looking at the patch it seems obvious that this functionality was
intentional at least for having a PKCS11 MAC. Do we really want to
removbe that Option and if yes des it require some form of aproval
Looking at the patch it seems obvious that this functionality was intentional
at least for having a PKCS11 MAC. Do we really want to removbe that Option and
if yes des it require some form of aproval?
(I think the change is good in General but that case Needs to be decided).
Since this is relae
Hi Adam, thanks for taking a look at this. Comments are in-line:
On 3/14/19 7:53 AM, Adam Petcher wrote:
The change to PBKDF2KeyImpl.java looks fine. About the test:
*) Is it necessary to put the provider in a separate jar? It seems
unnecessary because you are adding it with Security.insertPr
The change to PBKDF2KeyImpl.java looks fine. About the test:
*) Is it necessary to put the provider in a separate jar? It seems
unnecessary because you are adding it with Security.insertProviderAt.
*) Line 54 of the test compares the result of a constructor to null.
Unless I'm missing somethi
On 3/14/19 3:31 AM, Andrew John Hughes wrote:
> I've filed
> https://bugs.openjdk.java.net/browse/JDK-8220641
Yes, let's RFR and push that too.
> for that issue and generated a new webrev for 8175120:
>
> https://cr.openjdk.java.net/~andrew/openjdk8/8175120/webrev.02/
Looks good!
-Aleksey
Hello all,
This review will change the SunJCE implementation of PBKDF2 so that it
always uses the SunJCE version of the PRF algorithm internally.
Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8218723/webrev.01/
JBS: https://bugs.openjdk.java.net/browse/JDK-8218723
CSR: https://bugs.open
Yes, I was thinking that might be a good idea too. I'll make that
change shortly.
Thanks,
--Jamil
On 3/14/19 5:46 AM, Sean Mullan wrote:
Jamil,
I think it might make sense to change the bug synopsis since it isn't
really ignoring the provider argument.
Maybe "Use SunJCE Mac in SecretKeyF
Jamil,
I think it might make sense to change the bug synopsis since it isn't
really ignoring the provider argument.
Maybe "Use SunJCE Mac in SecretKeyFactory PBKDF2 implementation".
Thanks,
Sean
On 3/13/19 12:56 PM, Adam Petcher wrote:
Looks good. I added myself as a reviewer.
On the subje
12 matches
Mail list logo
