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.ni...@oracle.com>
*Gesendet: *Donnerstag, 14. März 2019 16:36
*An: *OpenJDK Dev list <mailto:security-dev@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
