<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hello Bernd, once again I appreciate your comments and have some of
my own in-line,<br>
<br>
<div class="moz-cite-prefix">On 3/14/2019 9:30 AM, Bernd Eckenfels
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:5c8a81bc.1c69fb81.632f5.56b9@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;}
/* 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>
<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>
</div>
</blockquote>
JN: Is there no case? None that I'm aware of, none that have caused
any bugs that I know of - the SecretKey object is made within
SunJCE's PBKDF2KeyImpl code (looks like it is just a SecretKey
wrapper around the password bytes). It seems like it should work
for pretty much any password handed in AFAICT.<br>
<br>
If you were going to have a FIPS keystore come into play, why would
you not use that 3rd party provider for the PBKDF2 SecretKeyFactory
in its entirety? That way the resulting SecretKey from a generation
operation would hopefully live on the FIPS keystore serviced by that
provider. For SunJCE I think you'd end up having a SecretKey that
lived in SunJCE since you're only going to a 3rd party provider for
the HMAC calculations. It just feels a little odd to hang a
security argument on a 3rd party provider for HMAC, but be willing
to do the encompassing PBKDF2 on SunJCE.<br>
<br>
All that said, I think even if HMAC is obtained from SunJCE, the
underlying MessageDigest probably would come from that 3rd party
provider. But of course there's no key involved, no init to be
done, so it's less prone to going wonky.<br>
<blockquote type="cite"
cite="mid:5c8a81bc.1c69fb81.632f5.56b9@mx.google.com">
<div class="WordSection1">
<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>
</div>
</blockquote>
JN: An option, certainly, but one that would mean at least an API
change to PBEKeySpec so the Mac could be passed into the
SecretKeyFactory. That would require much more careful
consideration and it would prevent backporting this bugfix since
PBEKeySpec is set in stone for any released JDK.<br>
<br>
<blockquote type="cite"
cite="mid:5c8a81bc.1c69fb81.632f5.56b9@mx.google.com">
<div class="WordSection1">
<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>
</div>
</blockquote>
JN: Generally yes, but not for a case where you ask explicitly for
PBKDF2 on SunJCE like SecretKeyFactory.getInstance(String algorithm,
String provider). That's what happened when the bug occurred.
While I don't think it would happen otherwise on BC FIPS (I haven't
checked but I assume it has PBKDF2WithHmacSHA1), it is possible for
automatic selection to land on SunJCE for that SKF algorithm if some
other higher priority provider doesn't have PBKDF2WithHmacSHA1, but
does have HmacSHA1 with some FIPS-like key restrictions (which seems
like a realistic possibility).<br>
<blockquote type="cite"
cite="mid:5c8a81bc.1c69fb81.632f5.56b9@mx.google.com">
<div class="WordSection1">
<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>
</div>
</blockquote>
JN: If you look at the original bug the stack trace is there. In
short BC is throwing org.bouncycastle.crypto.IllegalKeyException
because the key that is being handed to it while running in FIPS
mode is less than 112 bits (according to the exception message).<br>
<blockquote type="cite"
cite="mid:5c8a81bc.1c69fb81.632f5.56b9@mx.google.com">
<div class="WordSection1">
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Gruss</p>
<p class="MsoNormal">Bernd</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 17:18<br>
<b>An: </b><a href="mailto:ecki@zusammenkunft.net"
moz-do-not-send="true">Bernd Eckenfels</a>; <a
href="mailto:security-dev@openjdk.java.net"
moz-do-not-send="true">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" moz-do-not-send="true"><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"
moz-do-not-send="true">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"
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.<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/"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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>
</blockquote>
<br>
</body>
</html>