Hi Robert, Thanks for your input. However JCA supports pluggable providers. So by having an implementation based on JCA in Sling one could either use:
a) JRE built in providers like SUN JCE b) third party providers like Bouncycastle Using b) would require to have some kind of class loading compliant with OSGi for the providers (https://docs.oracle.com/javase/8/docs/api/java/security/Provider.html), but I hope to be able it is possible to have something pluggable and discoverable, so that it works out of the box. In the worst case we need to have some glue code, i.e. a Factory for https://github.com/apache/sling-org-apache-sling-commons-crypto/blob/master/src/main/java/org/apache/sling/commons/crypto/CryptoService.java which takes a provider as argument in order to use providers not being exposed from the System Bundle (i.e. JRE). Does anyone know if there is specific OSGi support for provider discovery outlined in https://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html -> Registering the Provider? Dynamically registering a provider via https://docs.oracle.com/javase/8/docs/api/java/security/Security.html#insertProviderAt-java.security.Provider-int- is IMHO not yet supported via some OSGi helper class (similar to https://aries.apache.org/documentation/modules/spi-fly.html) so that is something which needs to be written as well. Then one could use the provider from Commons Crypto via https://docs.oracle.com/javase/8/docs/api/java/security/Security.html#getProvider-java.lang.String- (identified via name) to specifically select a dedicated provider (like Bouncycastle) without necessarily replacing the JRE default (SUN JCE). Regards, Konrad > On 22. Jul 2026, at 12:24, Robert Munteanu <[email protected]> wrote: > > Hi Konrad, > > On Wed, 2026-07-22 at 10:29 +0200, Konrad Windszus wrote: >> Hi, >> Unfortunately Jasypt used in Commons Crypto >> (https://sling.apache.org/documentation/bundles/commons-crypto.html) >> is no longer maintained: >> >>> This library is no longer maintained, but it is kept here for >>> historical reference. A lot of effort went into it back in the day, >>> and I wouldn't want to just delete it. >> >> (From https://github.com/jasypt/jasypt/blob/master/README.md) >> >> Would it make sense to come up with an implementation based on the >> JCA >> (https://docs.oracle.com/javase/8/docs/technotes/guides/security/cryp >> to/CryptoSpec.html#ProviderArch) >> That way one would have the option to pick between different >> providers. The default one shipping with most JREs ("Sun JCE >> provider, >> https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJCEProvider >> ) already provides quite some algorithms. >> Bouncycastle is an alternative provider supporting even more >> algorithms: >> https://www.bouncycastle.org/documentation/specification_interoperability/#algorithms-and-key-types >> . > > Yes, I think it makes a lot of sense to move away from Jasypt. I have > no strong opinion on whether we should use JCA or Bouncycastle. > > Thanks, > Robert > >> >> In the end I would like to hook this up with CACs >> (https://sling.apache.org/documentation/bundles/context-aware-configu >> ration/context-aware-configuration.html) so that a property is >> optionally only stored in an encrypted fashion (right now this is >> always stored as plain text JCR property which is not suitable for >> secret data). >> >> WDYT? >> Konrad
