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 subject of PBKDF2With<PRF-We-Don't-Have>: your response makes
sense. I was concerned about a situation in which we parse the algorithm
name (similar to Cipher transforms), but it looks like that doesn't
happen here.
On 3/13/2019 11:48 AM, Jamil Nimeh wrote:
Hi Adam, thanks for the feedback. I have some comments below:
On 3/13/2019 6:44 AM, Adam Petcher wrote:
On 3/12/2019 2:33 PM, Jamil Nimeh wrote:
Hello all,
Please review the CSR for the behavioral change to SunJCE's PBKDF2
implementaion. This change will make the underlying Mac also come
from SunJCE. This change only affects the SunJCE implementation of
PBKDF2, not any other implementation from any different provider.
https://bugs.openjdk.java.net/browse/JDK-8220531
Looks pretty straightforward. I just have a couple of questions
related to compatibility:
1) Is it possible that the requested Mac would not be available in
SunJCE, but it would be available in some other provider? If so, then
PBKDF2 would fail after this change. Should we fall back to the
current behavior if we get a NoSuchAlgorithmException from SunJCE?
JN: It seems unlikely that we would make a SunJCE implementation of a
given PBKDF2With<prf> if we also don't support the PRF portion. At
least up to now we have always supported the PRFs (Hmacs mainly) on
SunJCE as well. It would concern me if we were trying to make a
SecretKeyFactory PBKDF2With<PRF-We-Don't-Have> because, short of a 3rd
party provider that has it, it would never work.
2) Do you (or anyone else on the mailing list) have any reason to be
concerned that the Mac in SunJCE won't work as well in some cases
where it could also come from another (higher-priority) provider? If
so, then we should think about adding a system property or other
toggle for this behavior. This is a question---not a suggestion. I
don't think we should include this toggle unless we have some
motivation to do so.
JN: I'd really prefer to not add yet another property to control
something like this if we don't have to. If you're selecting SunJCE
to do PBKDF2 it seems (to me at least) that you're already willing to
accept that the crypto operations happen in SunJCE software and the
PRF is really the core of that operation. Given that a higher
priority 3rd party provider can hamstring (in admittedly rare cases)
SunJCE's implementation, I'd much rather see SunJCE always work
regardless of 3rd party provider configuration than see the underlying
PRF move to another provider.
Also, if there is no change to any spec, then I think that means the
scope is "Implementation" rather than "SE".
JN: I'll make that change.
