Summary

The SunJCE implementation of PBKDF2 will have its underlying pseudorandom function (PRF), a Mac object, be obtained directly from the SunJCE provider.

Problem

Currently the Mac object that is used to perform the PRF portion of the PBKDF2 implementation is obtained only by specifying the algorithm. This means that it can be an implementation from a different provider than the one handling the PBKDF2 itself. While on its face this seems like a good thing, JDK-8218723 shows that it is possible to use a 3rd party provider to hamstring the SunJCE implementation of PBKDF2, even when the PBKDF2 algorithm is requested directly from the SunJCE provider rather than going through automatic provider selection. This SunJCE PBKDF2 failure happens in cases where SunJCE is selected for the PBKDF2 algorithm, but the underlying PRF comes from a different, higher priority, provider. If that implementation has extra restrictions on keys it can prevent the PBKDF2 from succeeding in all cases when the Mac.init fails.

Solution

The solution is to have the underlying Mac.getInstance call obtain the Mac implementation from the SunJCE provider. Since SunJCE has already been selected for PBKDF2, it makes sense that the underlying Mac also be performed on the same provider. This also prevents a 3rd party provider's implementation of the PRF from possibly preventing the PBKDF2 operation from succeeding.

Specification

There are no specification changes. The code changes are limited to the SunJCE PBKDF2 internal implementation.