<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi David,</p>
<p>I took a look and unfortunately what you propose won't work, for
at least 2 reasons.</p>
<p>First (the main and show-stopping technical issue), those
provider-based algorithms you mention are apparently for the
KeyAgreement service of the Java security framework. It seems
those combine the key agreement op with the KDF op all in one go?</p>
<p>That won't work for our design because we're modeling the
requirements of XML Encryption 1.1 where the KA and KDF ops are
conceptually completely separate. They are defined separately,
have distinct XML representations, etc, so one can mix-and-match
KA algo and KDF algo.</p>
<p>So in OpenSAML we have distinct KA and KDF interfaces and then
various impls for each. For example we have interface
org.opensaml.xmlsec.derivation.KeyDerivation. The ConcatKDF impl
of that in question that threw a NoClassDefFoundError with FIPS
was our org.opensaml.xmlsec.derivation.impl.ConcatKDF, which
imports these KDF-related classes (along with some needed BC
digest classes):</p>
<p><font face="monospace">import
org.bouncycastle.crypto.agreement.kdf.ConcatenationKDFGenerator;<br>
import org.bouncycastle.crypto.params.KDFParameters;</font><br>
</p>
<p>It was specifically throwing on not finding
org.bouncycastle.crypto.DerivationParameters, which is the
interface implemented by the above BC KDFParameters. For
reference that source is here:</p>
<p><a class="moz-txt-link-freetext" href="http://git.shibboleth.net/view/?p=java-opensaml.git;a=blob;f=opensaml-xmlsec-impl/src/main/java/org/opensaml/xmlsec/derivation/impl/ConcatKDF.java;hb=refs/heads/main">http://git.shibboleth.net/view/?p=java-opensaml.git;a=blob;f=opensaml-xmlsec-impl/src/main/java/org/opensaml/xmlsec/derivation/impl/ConcatKDF.java;hb=refs/heads/main</a><br>
</p>
<p>By contrast, for PBKDF2 we are using the SecretKeyFactory service
with the JDK-provided algorithm support for "PBKDF2With*"
(completed with the appropriate PRF algo ID). So if the BC
provider had a SecretKeyFactory impl for ConcatKDF by itself, that
would be closer to our needs. But....</p>
<p>Second, it's unlikely we could introduce a deployment requirement
for people to add the BC provider declaratively in java.security
and also questionable for us to add the BC provider
programmatically by default. As a library OpenSAML probably
shouldn't muck with people's environments like that.</p>
<p>And in XML Encryption 1.1, ConcatKDF is the
mandatory-to-implement KDF (PBKDF2 is optional). For that reason
it is our default KDF for ECDH, and it needs to work
out-of-the-box. So hopefully you can see that adding a
requirement on configuring a third-party provider would be an
issue for us. Our team can discuss further the idea of
automagically/programmatically adding in BC. I personally am not
a fan of the idea. But unless/until BC has a provider-based impl
of the ConcatKDF by itself, it's essentially a moot question.</p>
<p>I guess what I would ask about the FIPS version is: If the
provider there fundamentally supports ConcatKDF via the
KeyAgreement algorithms you mention, then why aren't the KDF
interfaces/impls there as well? Probably they are there but just
with different package and/or class names, etc? If they are, then
you know, that means the FIPS version really isn't a drop-in
replacement for the regular library, so it's going to be
challenging for us as a downstream consumer to overcome that.<br>
</p>
<p>Thanks,<br>
Brent</p>
<p><br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 7/13/21 10:30 PM, David Hook wrote:<br>
</div>
<blockquote type="cite"
cite="mid:029f362c-698c-41ce-1a0d-8c75fd5b1624@cryptoworkshop.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">Hi Brent,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I'd like to suggest that it gets
changed to use the BC provider rather than the BC low-level API.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">For some reason I can't connect to
any of the nabble references, so I can't easily find the source
file concerned, but from what I understand V4.1 added support
for the ConcatKDF key derivation function with ECDH. When I
checked the code this looked like something the BCFIPS provider
supports already (and the BC provider) for the JCE. The
agreement algorithms ending in CKDF use the concat KDF function.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">The following ones are currently
available in both providers:</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">ECCDHWITHSHA1CKDF<br>
ECCDHWITHSHA256CKDF</div>
<div class="moz-cite-prefix">ECCDHWITHSHA384CKDF<br>
</div>
<div class="moz-cite-prefix">ECCDHWITHSHA512CKDF</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I have subscribed to the dev list if
you would prefer to continue the discussion there. If you would
include the link to the source file either way we should be able
to work something out that will work for both providers (as I
have commit access to both, you'd hope so!).</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Let me know,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Thanks,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">David<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 14/7/21 7:17 am, Brent Putman
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:82b98164-38f8-07b9-7e98-c16a15b84c08@georgetown.edu">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p>Hello,</p>
<p>Sorry David (Hook) that I didn't get back to you when I
returned from vacation a couple of weeks ago, I unfortunately
overlooked that email todo.</p>
<p>I'm interested to hear what you had in mind. If possible it
would be great to have this discussion over on the
Shibboleth/OpenSAML developers list, so that other members of
the team and community can be aware and participate:</p>
<p><a class="moz-txt-link-freetext"
href="https://shibboleth.net/mailman/listinfo/dev"
moz-do-not-send="true">https://shibboleth.net/mailman/listinfo/dev</a><br>
</p>
<p>Thanks,<br>
Brent</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 7/9/21 11:54 AM, David Castro
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAN0SfypGqdg1U6tr1m0EBRVDotj-f64CcKRVQtyaeDMq-R-8dA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<div dir="ltr">Brent,
<div><br>
</div>
<div>Just wanted to follow up Re: the following thread on
the FIPS issue we were having.</div>
<div>
<div><a
href="https://shibboleth.1660669.n2.nabble.com/Bouncy-Castle-FIPS-Issue-td7649455.html#a7649653"
moz-do-not-send="true"><br
class="gmail-Apple-interchange-newline">
https://shibboleth.1660669.n2.nabble.com/Bouncy-Castle-FIPS-Issue-td7649455.html#a7649653</a></div>
<div>
<div><br>
</div>
</div>
</div>
<div>We spoke with David Hook from Bouncy Castle (included
in this thread) and he had some ideas on resolving the
issue. Scott Cantor recommended you as the point of
contact, but let us know if there is someone else we
should reach out to.</div>
<div><br>
</div>
<div>
<div>We are also available to assist as needed.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>David</div>
<div><br>
</div>
-- <br>
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr"><span
style="color:rgb(0,112,192);font-family:Verdana,sans-serif;font-size:13.3333px">CONFIDENTIALITY
NOTICE: </span><span
style="color:rgb(0,112,192);font-family:Verdana,sans-serif;font-size:13.3333px;background-image:initial;background-position:initial;background-repeat:initial">This
transmission, and any attachments, may contain
CONFIDENTIAL, PRIVILEGED or PROPRIETARY information
of HRworx, LLC (dba Intelliworx) that is protected
from disclosure under applicable laws. If you are
not the intended recipient, any disclosure, copying,
distribution, or use of any of the information
contained in or attached to this transmission is
STRICTLY PROHIBITED. </span><span
style="color:rgb(0,112,192);font-family:Verdana,sans-serif;font-size:13.3333px">If
you have received this communication in error,
please notify the sender, by reply e-mail, and
delete the original message with any attachments.
Thank you for your cooperation.</span><br>
</div>
</div>
</div>
</div>
</blockquote>
</blockquote>
<p><br>
</p>
</blockquote>
</body>
</html>