A split seems reasonable. We were amazed at how few changes you had to make to support OpenSSL 3.x. The EVPs are very different. But it sounds like there's more to do.
The problem with commons-codec is that it doesn't use OpenSSL or any other FIPS-certified cryptographic module. For example, HmacUtils uses Mac, which is supplied by the JRE, which isn't FIPS-certified. In order to qualify for FedRAMP High, which is table stakes for a lot of corporate and government contracts, FIPS has to be used. It's mandated by statute. No wiggle room. The promise of bc-fips is that it is FIPS-certified, is a JSP, and implements the full JCE. The drawback is that the bc-fips org is funded through donations and consulting, and is always very far behind Java releases (it's still on Java 11, for example). What we need is a full-featured JSP that is based on a FIPS-certified cryptographic module that is implemented using native code and JNI. We can get FIPS-certified digests and HMAC from openssl4j. What we need from commons-crypto are the ciphers, and they need to be on OpenSSL 3.0.8. If there's anything we can do to help make that happen, please let us know. On Mon, Jul 31, 2023 at 2:58 PM Gary Gregory <garydgreg...@gmail.com> wrote: > Hi Jim, > > My branch has not been merged because it does not fully work. It's > challenging to update the code such that one can use either OpenSSL 1.1.1 > or 3.0.0 or both. We might need the component split into more than one > Maven module. > > The name commons-crypto might have been poorly chosen because it's current > remit is an OpelSSL wrapper. That said there is room for more features, > which may mean splitting things up into more than one Maven module. > > Commons Code provides more convenience wrappers for JRE message digests > including HMAC: > https://commons.apache.org/proper/commons-codec/apidocs/index.html > > Are you looking to wrap or implement HMAC and message digests differently? > > Gary > > > On Mon, Jul 31, 2023, 5:04 PM Jim Showalter <jamesleeshowal...@gmail.com> > wrote: > > > We are trying to replace bc-fips ( > https://www.bouncycastle.org/fips-java/) > > with a JSP that is based on a cryptographic module that is 1) a native > > library and 2) is certified for FIPS 140-2 ( > > https://csrc.nist.gov/pubs/fips/140-2/upd2/final). > > > > A native library is faster, plus it doesn't entangle the Java classpath > > with restrictions on Java versions or load order the way bc-fips does. > > > > The two available native libraries we're aware of are BoringSSL and > > OpenSSL. > > > > For various reasons, we want to use OpenSSL. > > > > OpenSSL 1.1.1 was only FIPS-certified on RedHat (and they had to modify > it > > to add FIPS support), and the certification expires soon. > > > > OpenSSL 1.1.1 is the version commons-crypto is currently based on. > > > > OpenSSL 3.0.8 is FIPS-certified on a variety of platforms, supports FIPS > > mode natively, and its successor (3.1.x) will be certified for FIPS > 140-3. > > > > We're very interested in > > https://github.com/garydgregory/commons-crypto/tree/openssl3, which adds > > support for OpenSSL 3.0.8 to commons-crypto, per > > https://issues.apache.org/jira/browse/CRYPTO-164. > > > > But that PR was never merged, hasn't been touched since December 20, > 2022, > > and is currently 92 commits behind the main branch. > > > > What would it take to update that PR with all of the commits since then, > > and get it merged? > > > > Once that's done, we'd be happy to submit a PR to add FIPS mode, per > > https://issues.apache.org/jira/browse/CRYPTO-136. > > > > Also, commons-crypto doesn't support message digests or HMAC. We're in > the > > process of adding HMAC and FIPS mode to > > https://github.com/sfuhrm/openssl4j, > > which has message digests, and targets OpenSSL 3.0.8. > > > > It seems like the message digests and HMAC from openssl4j could be merged > > into commons-crypto, to bring it closer to being a full JCE > implementation. > > Is there any interest in seeing that happen? > > >
