<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<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">I think I just need some more
information.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">When you say output byte[] of the
KeyAgreement op, where does that come from? As in what code is
producing that? Would you point me at the file that's calling the
KDFConcat derive() method - referring to the source is generally
the least ambiguous way of sorting these things out.<br>
</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</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 15/7/21 10:55 am, Brent Putman
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:26234ffd-3e7c-f1d7-c645-2c8234d9a892@georgetown.edu">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<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>
</blockquote>
<p><br>
</p>
</body>
</html>