AES encryption leaks memory and performance

[Former user]

Encrypting using JWEAlgorithm.RSA_OAEP, EncryptionMethod.A128GCM, uses BouncyCastle AES but leaks memory excessively. This is because the nimbus AES class keeps instantiating a new BouncyCastleProvider and KeyGenerator (and possibly other BouncyCastle resources?).

This causes multiple BouncyCastle implementations to be instantiated (which is very slow) and also they get attached to the java security subsystem which causes a leak of approx 300k per call! This makes this encryption mode unusable.

AES.java needs changing to use a static/cached reference or the java security subsystem.

[Vladimir Dzhuvinov]

Thanks for reporting this issue. We'll try to address it asap.

[Vladimir Dzhuvinov]

There are two places where a BouncyCastle JCE provider is needed - in the ECKey class and in the AES utility class, to obtain a javax.crypto.KeyGenerator. I created a singleton to ensure only one instance is every created. See commit ceb8076.

Will now check if BouncyCastle offers an alternative mean to obtain the said KeyGenerator, so that we no longer need to get a full-blown JCE instance for that.

[Vladimir Dzhuvinov]

Filed a new issue to refactor AES key generator is that the full-blown BC JCE provider is not required for that:

https://bitbucket.org/nimbusds/nimbus-jose-jwt/issue/69/implement-lightweight-method-to-generate

The KeyGenerator is not supposed to leak, according to its specification, see the javax.crypto.KeyGenerator JavaDocs. It can be reused, also according to the JavaDocs, but in our case that would require the implementation to be thread-safe and I need to study this. I remember reading somewhere that that the underlying SecureRandom generators are typically thread-safe.

[Vladimir Dzhuvinov]

The fix was pushed into a new release (2.19.1) which should reach Maven Central soon. Thanks again for spotting this bug. If you encounter any other problems or have suggestions to improve the library, just let us know.