Problem

The library hardcodes "BC" as the JCE provider name in several getInstance() calls, which prevents it from working in FIPS (Federal Information Processing Standards) environments where the BouncyCastle FIPS provider ("BCFIPS") is registered instead of the standard provider ("BC").

Affected code

HttpEce.java — literal "BC" strings:

• Cipher.getInstance("AES/GCM/NoPadding", "BC") (lines 68, 140)

Utils.java — uses BouncyCastleProvider.PROVIDER_NAME (which resolves to "BC"):

• KeyFactory.getInstance(ALGORITHM, PROVIDER_NAME) (4 call sites)

The KeyAgreement.getInstance("ECDH") calls in HttpEce.java already omit the provider argument and would work fine in FIPS as-is.

Suggested fix

The standard JCE practice is to omit the provider argument and let the framework pick the best registered provider:

// Current — breaks in FIPS
Cipher.getInstance("AES/GCM/NoPadding", "BC")

// Option A — provider-agnostic (recommended if no BC-specific behavior is needed)
Cipher.getInstance("AES/GCM/NoPadding")

// Option B — configurable provider
Cipher.getInstance("AES/GCM/NoPadding", this.providerName)

The algorithms used (ECDH, AES-GCM, EC key generation on P-256) are all supported by standard JCE providers and by BCFIPS, so there is no technical reason to pin to "BC".

Option A is the simplest change. Option B (adding a setProvider(String) or constructor parameter) would give consumers explicit control.