[9] review request for 6977937: The SunJCE PBKDF2KeyImpl is requiring the MAC instance also be from SunJCE.

Anthony Scarpino anthony.scarpino at oracle.com
Wed Apr 9 16:55:19 UTC 2014


If my memory is right I think performance gains via hardware were limited with MAC algorithms. Also isn't PBKDF2 only for small operations?  Because searching for another provider could take longer than doing the operation in SunJCE

Tony

> On Apr 7, 2014, at 12:21 PM, Bradford Wetmore <bradford.wetmore at oracle.com> wrote:
> 
> 
> 
> 
>> On 4/5/2014 8:00 AM, Vincent Ryan wrote:
>> 
>> I was concerned about the impact on applications of a different JCE
>> provider being selected instead of SunJCE, on some platforms.
>> 
>> I can change the fix to follow the standard JCE provider ordering.
> 
> That would be my preference, but I can see both sides if someone has a strong case.
> 
> Brad
> 
> 
>> 
>>> On 04/04/2014 22:23, Bradford Wetmore wrote:
>>> With the current and proposed code, you are effectively requiring the
>>> MAC come from JCE, as all the algorithms exist in SunJCE.
>>> 
>>> IIRC, when we discussed the previous change in this area, the idea was
>>> that the MAC would follow the standard JCA provider priority ordering.
>>> 
>>> Brad
>>> 
>>> 
>>> 
>>>> On 4/4/2014 8:45 AM, Vincent Ryan wrote:
>>>> Hello,
>>>> 
>>>> Please review the following fix to remove the requirement for the Mac
>>>> algorithm used by a PBKDF2 algorithm to be supplied by the SunJCE
>>>> provider.
>>>> The SunJCE provider is still preferred (for compatibility with
>>>> previous releases and for performance reasons) but it is no longer
>>>> required.
>>>> The com.sun.crypto.provider.PBKDF2KeyImpl class first searches SunJCE
>>>> for the required Mac algorithm but fails over to searching the
>>>> other installed JCE providers too.
>>>> 
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6977937
>>>> Webrev: http://cr.openjdk.java.net/~vinnie/6977937/webrev.00/
>>>> 
>>>> Thanks.
>> 



More information about the security-dev mailing list