Change your cryptography
without changing your code.
Policy-driven crypto-agility: change and enforce algorithms — including migration to NIST post-quantum standards — across your Java estate without re-engineering applications, so old data stays decryptable through every transition.
For applications integrated via the Antrapol JCE provider · Java 17 · aligned with NIST FIPS 203 / 204 / 205
import javax.crypto.Cipher;
import com.antrapol.jce.Antrapol;
Antrapol.install(); // register the policy-driven JCE provider
// No algorithm hardcoded — resolved by business purpose,
// governed centrally by policy, self-describing on output.
Cipher c = Cipher.getInstance("agility/encrypt-user-password", "Antrapol");
c.init(Cipher.ENCRYPT_MODE, key);
byte[] out = c.doFinal(plaintext);
// 'out' carries the agility envelope: algorithm, version,
// mode, padding, IV, salt, iteration count — so it stays
// decodable after the policy switches algorithms.
The foundation of the MyPQC platform — governed, agile, standards-aligned
The problem
Algorithms have expiry dates. Your code shouldn't.
Cryptography embedded in source code is a liability the moment a standard changes — and a standard is changing right now.
Hardcoded algorithms
Applications embed choices like AES-128 or SHA-256 directly in source. Changing one means code edits, testing and redeployment across every affected system — slow and risky exactly when speed matters.
No central governance
CISOs lack a single way to enforce or audit which algorithms are actually in use. Compliance reporting is manual, error-prone and incomplete.
Broken backward compatibility
Migrate from one algorithm to another and yesterday's ciphertext and signatures must still verify and decrypt. Without encoded metadata, that means fragile custom logic in every app.
A closing PQC window
Under NIST's proposed transition roadmap (draft IR 8547), RSA-2048 and ECC P-256 are set to be deprecated around 2030 and RSA/ECC disallowed around 2035. Migrations must be ready, not improvised.
Fragmented cipher parameters
Salts, IVs, iteration counts and key-derivation configs are handled inconsistently across systems, causing interoperability failures and subtle vulnerabilities.
Harvest now, decrypt later
Adversaries can capture encrypted data today and decrypt it once a cryptographically relevant quantum computer exists. Data with a 10–30 year confidentiality life is at risk now — whatever the exact timeline.
How it works
A policy-driven abstraction layer over the crypto you already call
The Crypto Agility Core Engine sits on top of established cryptographic APIs. Applications ask for a business purpose; policy decides the algorithm. The choice can change centrally, anytime, without a redeploy.
Resolve by purpose, not by name
Instead of hardcoding "AES-256/GCM",
apps request a cryptographic purpose — "encrypt user password", "sign API response",
"hash PII". The engine resolves that purpose to the currently active algorithm and
parameters by querying the policy service.
Self-describing agility envelope
At creation time the output is wrapped in a structured envelope encoding the algorithm identifier, version, key size, mode, padding, IV, salt and iteration count. At consumption time the envelope is decoded to reverse the operation correctly — so data produced under an old algorithm stays decryptable and verifiable after a switch.
Enforcement modes
Run policy in STRICT mode to reject non-conformant algorithm requests, WARN mode to surface violations while permitting them, or OFF to observe only. Weak legacy requests can be normalized upward to a hardened baseline as a matter of opinionated policy.
Delegate providers do the math
The engine registers as a Java Security Provider and, once the algorithm is resolved, delegates the actual operation to underlying providers such as SunJCE and BouncyCastle. Non-managed JCE calls are left untouched.
import java.security.Signature;
import com.antrapol.jce.Antrapol;
Antrapol.install();
// Policy-driven signing: the purpose maps to whichever
// signature algorithm policy currently mandates. Migrate
// an entire estate from RSA to ML-DSA by changing policy —
// not by editing or redeploying this code.
Signature signer =
Signature.getInstance("agility/sign-configuration", "Antrapol");
signer.initSign(privateKey);
signer.update(configBytes);
byte[] signature = signer.sign();
// The signature is agility-encoded; verification later
// reads the envelope to pick the right algorithm — even
// for artifacts signed before the policy changed.
Illustrative. Purpose identifiers and enforcement behaviour are configured centrally in the policy portal.
The two-phase model
Crypto agility for what you create. Cipher agility for what you already made.
Most agility tools only change algorithms going forward. Pairing creation-time policy with consumption-time decoding is what keeps historical data usable through every transition.
Crypto agility — the creation phase
Governs encryption, signing, hashing and key derivation. Intercepts the operation, applies the policy-mandated algorithm, and writes the agility envelope so every output is self-describing from the moment it is produced.
Cipher agility — the consumption phase
Governs decryption, verification and parsing. Reads the envelope to select the exact algorithm and parameters automatically — with configurable fallback policies for legacy data produced before deployment, and secure failure on tampered or unsupported envelopes.
Capabilities
Built for governed, enterprise-scale cryptographic change
Everything a CISO needs to see, control and prove the cryptographic posture of a Java estate — from one control plane.
Drop-in JCE integration
A custom Java Security Provider intercepts standard getInstance() calls, so existing crypto code becomes policy-governed with minimal refactoring.
Scheduled transitions
Define algorithm cutovers with effective dates — e.g. AES-128-CBC → AES-256-GCM for a purpose on a set date — and every connected system switches automatically.
Self-describing envelope
Deterministic, versioned, HMAC-protected metadata travels with each output, removing fragile per-application parameter handling.
Cryptographic inventory
A live dashboard of every registered purpose, its current algorithm mapping, transition history and connected systems.
Tamper-evident audit
RBAC, MFA on policy changes, and an exportable audit trail (PDF / CSV) that records who changed what, when.
Backward compatibility
Historical ciphertext and signatures keep decrypting and verifying with no application-side change, across any number of algorithm transitions.
Resilient by design
A fault-tolerant backend keeps resolving policy during central outages via local caching and active-active replication, so engines keep operating.
PQC-ready
Designed to extend to the NIST PQC families — ML-KEM (FIPS 203), ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) — so post-quantum migration becomes a policy change.
Protocol flexibility
The client selects its transport — gRPC, Dubbo Triple or REST/JSON — as configuration only, without touching cryptographic code.
Use cases
What crypto-agility unlocks
Bank or agency migrating RSA → ML-DSA
Move signing purposes from RSA to the NIST-standardized ML-DSA (FIPS 204) centrally, on a schedule, without re-engineering integrated systems. Signatures produced under RSA keep verifying through and after the cutover via the agility envelope.
Enforcing a hardened hashing baseline
Standardize on the SHA-3 family for a uniform, modern hashing posture across the estate. Set policy once; STRICT mode rejects non-conformant requests and the inventory dashboard proves the baseline is actually in force.
Sovereign algorithm selection
Where local policy calls for it, select a sovereign Malaysian scheme such as KAZ-SIGN as an optional, policy-selectable option offered alongside the NIST standards. Because the choice is policy-driven, it can be swapped back to a NIST algorithm at any time — sovereignty without lock-in.
A note on sovereign algorithms
The NIST-standardized algorithms — ML-KEM (FIPS 203), ML-DSA (FIPS 204) and SLH-DSA (FIPS 205), finalized in August 2024 — carry the assurance narrative. KAZ-SIGN is an optional, policy-selectable sovereign (Malaysian) signature option offered alongside those standards for organizations that want a locally-developed choice and reduced dependence on foreign standards. It is not a NIST-standardized, NIST-approved or FIPS algorithm, and we do not position it as equivalent to ML-DSA or SLH-DSA.
Crypto-agility is precisely what makes this safe: offering a sovereign option is not a bet on any single algorithm's long-term security — it is a policy choice the customer can change at any time, so you are never locked out of the global NIST ecosystem.
Standards & algorithms
Aligned with the standards, agile about the choice
The engine works through the standard JCE API and supports the major operation categories, with policy-driven agility from classical algorithms to the NIST PQC families.
| Operation category | Classical algorithms | Post-quantum path |
|---|---|---|
| Symmetric encryption | AES (incl. AES-256-GCM), ChaCha20 | Hybrid key establishment via ML-KEM |
| Asymmetric / key establishment | RSA, EC | ML-KEM — FIPS 203 |
| Digital signatures | RSA, ECDSA, EdDSA | ML-DSA — FIPS 204 · SLH-DSA — FIPS 205 · KAZ-SIGN (optional, sovereign) |
| Message digests | SHA-2, SHA-3 | SHA-3 preferred for a uniform posture |
| MAC | HMAC | Envelope integrity via HMAC |
| Key derivation | PBKDF2, Argon2 | Policy-selectable per purpose |
Make cryptographic change a policy setting, not a code project
See how the Crypto Agility Core Engine lets you migrate to post-quantum standards across your Java estate — without re-engineering applications.