RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ ) ignoresthe provider argument.

[Jamil Nimeh]

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 <mailto:jamil.j.nimeh at oracle.com>
> *Gesendet: *Donnerstag, 14. März 2019 16:36
> *An: *OpenJDK Dev list <mailto:security-dev at openjdk.java.net>
> *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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20190314/90f22847/attachment.htm>