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 FIPS provisions are more sad in that case…) Gruss Bernd -- http://bernd.eckenfels.net Von: Jamil Nimeh Gesendet: Donnerstag, 14. März 2019 18:16 An: Bernd Eckenfels; OpenJDK Dev list Betreff: Re: AW: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_)ignoresthe provider argument. 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 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 not allow to Export key material. JN: Is there no case? None that I'm aware of, none that have caused any bugs that I know of - the SecretKey object is made within SunJCE's PBKDF2KeyImpl code (looks like it is just a SecretKey wrapper around the password bytes). It seems like it should work for pretty much any password handed in AFAICT. If you were going to have a FIPS keystore come into play, why would you not use that 3rd party provider for the PBKDF2 SecretKeyFactory in its entirety? That way the resulting SecretKey from a generation operation would hopefully live on the FIPS keystore serviced by that provider. For SunJCE I think you'd end up having a SecretKey that lived in SunJCE since you're only going to a 3rd party provider for the HMAC calculations. It just feels a little odd to hang a security argument on a 3rd party provider for HMAC, but be willing to do the encompassing PBKDF2 on SunJCE. All that said, I think even if HMAC is obtained from SunJCE, the underlying MessageDigest probably would come from that 3rd party provider. But of course there's no key involved, no init to be done, so it's less prone to going wonky.  One Option would be to make the Mac an Parameter, then at least new Code could specify different implementers. It still would break existing PKCS11 deployments (at least for those where the keymaterial is not exportable) JN: An option, certainly, but one that would mean at least an API change to PBEKeySpec so the Mac could be passed into the SecretKeyFactory. That would require much more careful consideration and it would prevent backporting this bugfix since PBEKeySpec is set in stone for any released JDK.  I would argue that the case when you use a JCE PBKDF2 on a JVM where BC FIPS has higher prio would be wrong anyway. JN: Generally yes, but not for a case where you ask explicitly for PBKDF2 on SunJCE like SecretKeyFactory.getInstance(String algorithm, String provider). That's what happened when the bug occurred. While I don't think it would happen otherwise on BC FIPS (I haven't checked but I assume it has PBKDF2WithHmacSHA1), it is possible for automatic selection to land on SunJCE for that SKF algorithm if some other higher priority provider doesn't have PBKDF2WithHmacSHA1, but does have HmacSHA1 with some FIPS-like key restrictions (which seems like a realistic possibility).  I thin I havent seen what the case for the init falure in BC MAC was, is this also key related? JN: If you look at the original bug the stack trace is there. In short BC is throwing org.bouncycastle.crypto.IllegalKeyException because the key that is being handed to it while running in FIPS mode is less than 112 bits (according to the exception message).  Gruss Bernd -- http://bernd.eckenfels.net  Von: Jamil Nimeh Gesendet: Donnerstag, 14. März 2019 17:18 An: Bernd Eckenfels; OpenJDK Dev list Betreff: Re: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ )ignoresthe provider argument.  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?  (I think the change is good in General but that case Needs to be decided). JN: Yes, there is definitely an approval process which is in progress. The CSR link in the original email is the approval process for a behavioral change like this. The fix itself, even if it is good, won't go back until the CSR is approved. As far as a PKCS#11 Mac, or a Mac from any 3rd party is concerned: Ideally the underlying Mac should be able to come from 3rd party providers. And for a long time this worked. But now we're up against a case where a BC FIPS provider's HMAC implementation is causing the SunJCE PBKDF2 implementation to fail. And it fails not because the PRF algorithm isn't found, it fails on init. If we're requesting SunJCE by name (as it was in the case that caused the bug) the mere presence of BC FIPS as a higher priority provider shouldn't cause this kind of failure. There's nothing wrong with either provider in general, but the interaction between the two has had this unexpected consequence. There's no easy way get the best of both worlds. By the time we're down in the guts of the PBKDF2 key implementation where the PRF is instantiated, we know we're on the SunJCE provider, but we don't know *how* we got there (by automatic selection or by being chosen explicitly). So it's hard to make an intelligent decision about whether to use the SunJCE version (which will always work) or risk going out to a 3rd party provider (which usually works, but not in this case). Given the choice, I'm opting for "always working" since SunJCE was already selected (one way or the other) for PBKDF2. The PRF is the key cryptographic piece of that operation so it's not outrageous that it too should come from SunJCE.  Since this is relaed, using a whitebox prf would also allow to do precomputing of the first hmac block outside of the Iteration, thats an algorithmic speedup* which attackers implementations surely feature.  Gruss Bernd  * OPT-02 in https://afiuorio.github.io/assets/thesis_afi_msc.pdf -- http://bernd.eckenfels.net  Von: Jamil Nimeh Gesendet: Donnerstag, 14. März 2019 16:36 An: OpenJDK Dev list Betreff: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ ) ignoresthe provider argument.  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.openjdk.java.net/browse/JDK-8220531   Â
