cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: On BouncyCastle installed as a global security provider
Date Wed, 23 Jul 2014 09:57:14 GMT
Hi Alessio

In my new tests around JSON security I'm doing exactly what you propose, 
checking if BC is needed, apparently not with Java 8 only as far as GCM 
is concerned.

it may be more sensitive in case of WSS4J...

Cheers, Sergey
On 23/07/14 12:44, Alessio Soldano wrote:
> Hi,
> I've been asked whether it's possible to avoid having BC installed as a
> global security provider when using Apache CXF. I'm of course aware that
> WSS4J installs it on behalf of CXF for supporting e.g. GCM algorithms,
> which is not an option. However the question is still reasonable;
> assuming the CXF stack is not the only framework running in the JVM,
> other frameworks are going to be affected by that. They might or might
> not want BC installed (for instance, just an example, because of [1]).
> They might prefer different providers for a given set of algorithm
> requirements. Ultimately, it should be up to the user to decide which
> providers are set as global security provider, application should either
> rely on the installed global providers without touching them, or
> explicitly use what they want.
> So I'm wondering if there's a way we could modify CXF/WSS4J/Santuario
> for using BC (or whatever we want to use ;-) ) e.g. when needing GCM
> without installing it as a global provider. Something around e.g.
> getting ciphers through the javax.crypto.Cipher#getInstance(String
> transformation, Provider provider) method instead of the
> javax.crypto.Cipher#getInstance(String transformation) after having
> loaded the provider without installing it globally, etc.
> Any thought / idea?
> Thanks
> Alessio
> [1] /
>, BouncyCastle DH
> KeyPairGenerator algorithm can hang / eat lots of CPU

View raw message