<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:windowtext;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang=DE link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNormal>Hello,</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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)</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I thin I havent seen what the case for the init falure in BC MAC was, is this also key related?</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Gruss</p><p class=MsoNormal>Bernd</p><p class=MsoNormal>-- <br>http://bernd.eckenfels.net</p><p class=MsoNormal><o:p> </o:p></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal style='border:none;padding:0cm'><b>Von: </b><a href="mailto:jamil.j.nimeh@oracle.com">Jamil Nimeh</a><br><b>Gesendet: </b>Donnerstag, 14. März 2019 17:18<br><b>An: </b><a href="mailto:ecki@zusammenkunft.net">Bernd Eckenfels</a>; <a href="mailto:security-dev@openjdk.java.net">OpenJDK Dev list</a><br><b>Betreff: </b>Re: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ )ignoresthe provider argument.</p></div><p class=MsoNormal><o:p> </o:p></p><p>Hi Bernd, thanks for the feedback, comments below:</p><div><p class=MsoNormal><span style='color:black'>On 3/14/19 8:58 AM, Bernd Eckenfels wrote:<o:p></o:p></span></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal><span style='color:black'>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?<o:p></o:p></span></p><p class=MsoNormal><span style='color:black'> <o:p></o:p></span></p><p class=MsoNormal><span style='color:black'>(I think the change is good in General but that case Needs to be decided).<o:p></o:p></span></p></blockquote><p>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.</p><p>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.</p><p>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).</p><p>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.</p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal><span style='color:black'> <o:p></o:p></span></p><p class=MsoNormal><span style='color:black'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='color:black'> <o:p></o:p></span></p><p class=MsoNormal><span style='color:black'>Gruss<o:p></o:p></span></p><p class=MsoNormal><span style='color:black'>Bernd<o:p></o:p></span></p><p class=MsoNormal><span style='color:black'> <o:p></o:p></span></p><p class=MsoNormal><span style='color:black'>* OPT-02 in <a href="https://afiuorio.github.io/assets/thesis_afi_msc.pdf" target="_blank"><span style='font-size:10.0pt'>https://afiuorio.github.io/assets/thesis_afi_msc.pdf</span></a> <o:p></o:p></span></p><p class=MsoNormal><span style='color:black'>-- <br><a href="http://bernd.eckenfels.net">http://bernd.eckenfels.net</a><o:p></o:p></span></p><p class=MsoNormal><span style='color:black'> <o:p></o:p></span></p><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span style='color:black'>Von: </span></b><span style='color:black'><a href="mailto:jamil.j.nimeh@oracle.com">Jamil Nimeh</a><br><b>Gesendet: </b>Donnerstag, 14. März 2019 16:36<br><b>An: </b><a href="mailto:security-dev@openjdk.java.net">OpenJDK Dev list</a><br><b>Betreff: </b>RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ ) ignoresthe provider argument.<o:p></o:p></span></p></div><p class=MsoNormal><span style='color:black'> <o:p></o:p></span></p><p class=MsoNormal><span style='color:black'>Hello all,<o:p></o:p></span></p><p class=MsoNormal><span style='color:black'> <o:p></o:p></span></p><p class=MsoNormal><span style='color:black'>This review will change the SunJCE implementation of PBKDF2 so that it <o:p></o:p></span></p><p class=MsoNormal><span style='color:black'>always uses the SunJCE version of the PRF algorithm internally.<o:p></o:p></span></p><p class=MsoNormal><span style='color:black'> <o:p></o:p></span></p><p class=MsoNormal><span style='color:black'>Webrev: <a href="http://cr.openjdk.java.net/~jnimeh/reviews/8218723/webrev.01/">http://cr.openjdk.java.net/~jnimeh/reviews/8218723/webrev.01/</a><o:p></o:p></span></p><p class=MsoNormal><span style='color:black'> <o:p></o:p></span></p><p class=MsoNormal><span style='color:black'>JBS: <a href="https://bugs.openjdk.java.net/browse/JDK-8218723">https://bugs.openjdk.java.net/browse/JDK-8218723</a><o:p></o:p></span></p><p class=MsoNormal><span style='color:black'> <o:p></o:p></span></p><p class=MsoNormal><span style='color:black'>CSR: <a href="https://bugs.openjdk.java.net/browse/JDK-8220531">https://bugs.openjdk.java.net/browse/JDK-8220531</a><o:p></o:p></span></p><p class=MsoNormal><span style='color:black'> <o:p></o:p></span></p></blockquote><p class=MsoNormal style='mso-margin-top-alt:0cm;margin-right:36.0pt;margin-bottom:5.0pt;margin-left:36.0pt'><span style='color:black'> <o:p></o:p></span></p><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p></div></body></html>