<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,</p>
<p>The secret byte[] over which which the key derivation is
performed is literally a runtime argument. It's in the method
signature of the derive(...) method of the our KeyDerivation
interface:</p>
<p><a class="moz-txt-link-freetext" href="http://git.shibboleth.net/view/?p=java-opensaml.git;a=blob;f=opensaml-xmlsec-api/src/main/java/org/opensaml/xmlsec/derivation/KeyDerivation.java;hb=refs/heads/main">http://git.shibboleth.net/view/?p=java-opensaml.git;a=blob;f=opensaml-xmlsec-api/src/main/java/org/opensaml/xmlsec/derivation/KeyDerivation.java;hb=refs/heads/main</a></p>
<p>The ConcatKDF under discussion is just a concrete impl of that.<br>
</p>
<p>The XML Encryption model here - and reflected in our design - is
that key derivation is a first class concern. It intrinsically
has nothing to do with key agreement. For example, one can also
produce a symmetric key from a pre-shared secret + a KDF, which
the XML spec calls a DerivedKey.</p>
<p>So any approach that conflates/combines key agreement and key
derivation into a single monolithic operation is a non-starter for
this. That's the main point I was trying to make.</p>
<p>Thanks,<br>
Brent</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 7/14/21 9:28 PM, David Hook wrote:<br>
</div>
<blockquote type="cite"
cite="mid:b27de692-b816-7e83-bb1c-aadccabe7817@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">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>
</blockquote>
</body>
</html>