<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,</p>
<p>Either I don't think I understand, or maybe you misread our
code. AFAIK the KeyAgreement service interface requires the 2
Keys over which the key agreement is being performed. For example:</p>
<p><font face="monospace">keyAgreement =
KeyAgreement.getInstance(agreementAlgo);<br>
keyAgreement.init(privateKey);<br>
keyAgreement.doPhase(publicKey, true);<br>
</font></p>
<p>Our KeyDerivation impls like ConcatKDF do not have access to any
of the key agreement key material. They are about key derivation
from an input byte[] only (i.e. the output byte[] of the
KeyAgreement op). The do not and can not have access to any key
agreement key material, because it's out-of-scope for what they
do. So I don't see how we can re-implement our ConcatKDF
"SecretKey derive(...)" method using the KeyAgreement service
interface as you suggest.</p>
<p>Please clarify if I am missing something here.<br>
</p>
<p>Thanks,<br>
Brent<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 7/14/21 8:21 PM, David Hook wrote:<br>
</div>
<blockquote type="cite"
cite="mid:88483d0d-2de0-6f08-3e2e-d1081ffcd885@bouncycastle.org">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Hi Brent,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">It will work. The naming convention
is also to allow mixing and matching, you just need to add:<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">org.bouncycastle.jcajce.spec.UserKeyingMaterialSpec</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">as a parameter to the KeyAgreement.
It's unfortunate that the JCE doesn't define this parameter, so
I am not surprised you are not aware of it, but it's impossible
to use key agreement properly without it, and it exists in both
BC and BCFIPS specifically for situations like this.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">You use the UserKeyingMaterialSpec to
pass in otherInfo, which I can see is being constructed in
accordance with SP 800-56A which is the FIPS standard. There is
some BC support for otherInfo but we are using the ASN.1
construction, SP 800-56A allows for several others, and I'm not
sure what the XML standard settled on. You are probably better
off sticking to what you are doing now.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">For our part I think we'd just need
to add some additional KDF support for the non-NIST digests. In
the case of the SAML code it would just be a matter of replacing
SecretKey derive() I think and allowing for the
UserKeyingMaterialSpec construction.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Concerning your comments about BC
and BCFIPS. Yes the low level libraries are different, they have
to be, but we've been able to keep the JCE layer in sync since
1.58. The upside of this is it means if people swap in BCFIPS
rather than BC they can be confident the code is then FIPS
compliant. If you interested in finding out why the difference
exists, there is actually a document</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><a class="moz-txt-link-freetext"
href="https://www.bouncycastle.org/fips/BCFipsDescription.pdf"
moz-do-not-send="true">https://www.bouncycastle.org/fips/BCFipsDescription.pdf</a><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">which provides a summary. I would
recommend that over reading the FIPS IG and the 30 or so
associated documents that go with it unless you have a specific
interest. The same applies for Common Criteria. <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I don't think there will be any
end-user problems as the end result will be a massive broadening
of what the OpenSAML project can be used for.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Any further questions or issues,
please let me know.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Thanks,</div>
<div class="moz-cite-prefix"><br>
David<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 15/7/21 8:59 am, Brent Putman
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:6c8d1d8d-6f3c-561c-3422-81107b4410be@georgetown.edu">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<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"
moz-do-not-send="true">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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
</blockquote>
<p><br>
</p>
</blockquote>
</body>
</html>