<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi Bernd, thanks for the feedback, comments below:<br>
</p>
<div class="moz-cite-prefix">On 3/14/19 8:58 AM, Bernd Eckenfels
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:5c8a7a08.1c69fb81.9e9af.57df@mx.google.com">
<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;}
@font-face
{font-family:"Segoe UI";
panose-1:2 11 5 2 4 2 4 2 2 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
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>
<div class="WordSection1">
<p class="MsoNormal">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?</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">(I think the change is good in General but
that case Needs to be decided).<br>
</p>
</div>
</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.<br>
</p>
<blockquote type="cite"
cite="mid:5c8a7a08.1c69fb81.9e9af.57df@mx.google.com">
<div class="WordSection1">
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Gruss</p>
<p class="MsoNormal">Bernd</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">* OPT-02 in <a
href="https://afiuorio.github.io/assets/thesis_afi_msc.pdf"
target="_blank" moz-do-not-send="true"><span
style="font-size:10.0pt;font-family:"Segoe
UI",sans-serif;background:white;text-decoration:none">https://afiuorio.github.io/assets/thesis_afi_msc.pdf</span></a>
</p>
<p class="MsoNormal">-- <br>
<a class="moz-txt-link-freetext" href="http://bernd.eckenfels.net">http://bernd.eckenfels.net</a></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"
moz-do-not-send="true">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"
moz-do-not-send="true">OpenJDK Dev list</a><br>
<b>Betreff: </b>RFR 8218723: SecretKeyFactory.getInstance(
algo_, provider_ ) ignoresthe provider argument.</p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hello all,</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This review will change the SunJCE
implementation of PBKDF2 so that it </p>
<p class="MsoNormal">always uses the SunJCE version of the PRF
algorithm internally.</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Webrev:
<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~jnimeh/reviews/8218723/webrev.01/">http://cr.openjdk.java.net/~jnimeh/reviews/8218723/webrev.01/</a></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">JBS:
<a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8218723">https://bugs.openjdk.java.net/browse/JDK-8218723</a></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">CSR:
<a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8220531">https://bugs.openjdk.java.net/browse/JDK-8220531</a></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
</body>
</html>