...
The Java products we produce, including the Identity Provider and OpenSAML libraries, rely on the Java Cryptograpy Extensions service APIs for virtually all encryption, decryption, signing, and verification operations involving the core protocols we support. There are two exceptions worthy of note that apply to the V3+ Identity Provider and OpenSAML stack:
...
However, within the OpenSAML stack, a version of the Bouncy Castle library provides:
An ASN.1 parser and some certificate and key parsing functionality to one of our dependencies
- (V4.1+)
KeyInfo support for Elliptic Curve keys with Named Curves
- (V4.1+)
Our implementation of ConcatKDF key derivation for encryption using Elliptic Curve Diffie-Hellman (ECDH) key agreementOne implementation of the OpenSAML StorageService API in V3 is implemented on top of the Bouncy Castle AES-GCM implementation due to compatibility issues with Java 7. While it is used by default within the Identity Provider software, it is not a requirement, and was replaced by the Java implementation in V4
It is NOT possible with ordinary effort to switch the code base to rely on the Bouncy Castle FIPS version, as its API is not compatible with the full version to a sufficient enough degree. Until such time as we remove the dependency on it altogether, which is a goal of the project, the situation isn’t going to improve.
C++
The C++ products we produce, including the Service Provider and OpenSAML libraries, rely solely on OpenSSL for all underlying cryptographic operations. We do not have any specific knowledge as to the compatibility of such a the FIPS version with our code but would be happy willing to consider any patches necessary to allow for this. We have no plans to do such work ourselves, or to test it.