How to enable/configure BCFIPS to use AES NI for TLS data transfer

[vmwzhangv]

We are hitting a performance issue with BCFIPS when downloading files using HTTPS. Profiling reveals high cpu usage in the following call chain. This is some AES code in BCFIPS. The performance is 10x times slower than the linux wget command.
We are not sure that BCFIPS is leveraging the AES NI or not. This BCFIPS 2.0 on a Intel system.

Can you confirm/suggest ways to make BCFIPS use AES NI for TLS while keeping the FIPS compliance ? Some google search suggests to indirectly use the default java security provider for AES, but that would lose the FIPS compliance ?

org.bouncycastle.crypto.fips.AESEngine.processBlock()
org.bouncycastle.crypto.internal.modes.GCMBlockCipher.getNextCounterBlock()
org.bouncycastle.crypto.internal.modes.GCMBlockCipher.gCTRBlock()
org.bouncycastle.crypto.internal.modes.GCMBlockCipher.outputBlock()
org.bouncycastle.crypto.internal.modes.GCMBlockCipher.processBytes()
org.bouncycastle.crypto.internal.io.CipherOutputStreamImpl.write()
org.bouncycastle.crypto.UpdateOutputStream.update()
org.bouncycastle.jcajce.provider.BaseCipher.engineDoFinal()
javax.crypto.Cipher.doFinal(Cipher.java:2417)
org.bouncycastle.tls.crypto.impl.jcajce.JceAEADCipherImpl.doFinal(JceAEADCipherImpl.java:143)
org.bouncycastle.tls.crypto.impl.TlsAEADCipher.decodeCiphertext(TlsAEADCipher.java:303)
org.bouncycastle.tls.RecordStream.decodeAndVerify(RecordStream.java:255)
org.bouncycastle.tls.RecordStream.readRecord(RecordStream.java:240)
org.bouncycastle.tls.TlsProtocol.safeReadRecord(TlsProtocol.java:879)
org.bouncycastle.tls.TlsProtocol.readApplicationData(TlsProtocol.java:842)
org.bouncycastle.jsse.provider.ProvSSLSocketWrap$AppDataInput.read(ProvSSLSocketWrap.java:814)
org.apache.hc.core5.http.impl.io.SessionInputBufferImpl.read(SessionInputBufferImpl.java:195)
org.apache.hc.core5.http.impl.io.ContentLengthInputStream.read(ContentLengthInputStream.java:173)
org.apache.hc.core5.http.io.EofSensorInputStream.read(EofSensorInputStream.java:135)
org.apache.hc.core5.http.io.EofSensorInputStream.read(EofSensorInputStream.java:148)

[mwcw]

Hi,

BCFIPS 2.0 has no native code support.

You can use the DumpInfo command to get more information:

2.0:

java -cp jars/bc-fips-2.0.0.jar org.bouncycastle.util.DumpInfo 

Version Info: BouncyCastle Security Provider (FIPS edition) v2.0.0
FIPS Ready Status: READY
Module SHA-256 HMAC: 164c8ae41945cb85fdc65666fc4de7301a65d29659ecd455ee5199c7d42d107e

vs 2.1.0:

java -cp jars/bc-fips-2.1.0.jar org.bouncycastle.util.DumpInfo -verbose
Version Info: BouncyCastle Security Provider (FIPS edition) v2.1.0
FIPS Ready Status: READY
Native Ready Status: READY
Native Variant: vaesf
Native Build Date: 2024-11-15T15:56:42
Native Support: AES/CBC AES/CFB AES/CTR AES/ECB AES/GCM DRBG NRBG SHA2
Native Libs Available: true
Native Libs Installed: true
Native Status Message: READY

CPU Features and Variant availability.
--------------------------------------------------------------------------------
Variant   CPU features + or -:                              Supported           
--------------------------------------------------------------------------------
VAESF     +vaes +avx512f +avx512bw +vpclmulqdq              Variant supported
VAES      +vaes                                             Variant supported
AVX       +avx                                              Variant supported

Module SHA-256 HMAC: 941ebff8db149f871fbbeaf90269c19453b1e9d3777541fda1c0cf9132b426ce

MW

[vmwzhangv]

Oh! Great thanks! We will try BCFIPS 2.1

[vmwzhangv]

Is there a way to get the 2.1.0 version using maven ?
https://mvnrepository.com/artifact/org.bouncycastle/bc-fips

[dghgit]

2.1.0 is in the process of getting a certificate, as that is the case it's only available under the support early access program at the moment.

See https://www.keyfactor.com/open-source/bouncy-castle-support/ for details.

[vmwzhangv]

Any expectation when 2.1.0 might be publicly available ? Meanwhile, are there other options of fixing the performance issue ?

[dghgit]

Not at the moment, owing to the change in administration (I guess), things seem to be in a state of flux right now.