The registration of BouncyCastleProvider in SecurityUtil (core) with "Security.addProvider(new BouncyCastleProvider());" is changing JVM-settings and therefore all WARs in an Appserver are seeing this registration and classes of BouncyCastle.
If another WAR wants to use another version of BouncyCastle this can lead to Classloader issues. The Provider is also not removed on WAR-undeploy -> Memory-Leak.

In a WAR "Security.addProvider()" should be never used, because of all side-effects for other WARs ->

A simple fix would be:
private static final BouncyCastleProvider PROVIDER = new BouncyCastleProvider();

and then instead of Cipher.getInstance(ALGORITHM, "BC") -> Cipher.getInstance(ALGORITHM, PROVIDER)
or for KeyFactory
KeyFactory.getInstance(ALGORITHM, PROVIDER)

------------------------------------
If nobody is depending on the BouncyCastleProvider registration this fix should give no problems.

BouncyCastleProvider was introduced in MAGNOLIA-3904 -> by the way, I think only the dependency "bcprov-jdk16" is needed. I don't see a reason for "bcprov-ext-jdk16" and "bcpg-jdk16" introduced from MAGNOLIA-3904: bcprov-ext-jdk16 contains all classes of bcprov-jdk16 + IDEA cipher -> duplicate. bcpg-jdk16 -> Current code in core is not using OpenPGP

Attached is a patch for 4.5.10 which goes a step further: Using directly BouncyCastle instead of JCE-Wrapper-Classes, but it needs >= 1.48 of BouncyCastle for the Keygeneration. Except some error-messages the behavior should be the same as before (tested: patched author instance could communicate with an old public-instance).