Change your cryptography
without changing your code.
Policy-driven crypto-agility. It covers every language your estate runs from mobile to backend to web. Change and enforce algorithms. Migrate to NIST post-quantum standards without re-engineering applications. Old data stays decryptable through every transition.
Dart/Flutter for mobile · Java Security Provider for backend and security · PHP library for web admin
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. That includes the
// algorithm · version · mode · padding · IV · salt · iteration
// count. 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. 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 and testing and redeployment across every affected system. It is 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 and error-prone and incomplete.
Broken backward compatibility
Migrate from one algorithm to another and old ciphertext and signatures must still verify and decrypt. Without encoded metadata that means fragile custom logic in every app.
A closing PQC window
NIST's draft roadmap (IR 8547) phases out RSA-2048 and ECC P-256 around 2030. RSA and ECC are disallowed around 2035. Migrations must be ready. Not improvised.
Fragmented cipher parameters
Salts and IVs and iteration counts and key-derivation configs are handled inconsistently across systems. That causes interoperability failures and subtle vulnerabilities.
Harvest now and decrypt later
Adversaries can capture encrypted data today. They decrypt it later once a quantum computer is powerful enough. The exact timeline doesn't matter. Data that must stay secret for 10 to 30 years is at risk now.
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 at any time. No redeploy needed.
Resolve by purpose not by name
Apps don't hardcode "AES-256/GCM".
They request a cryptographic purpose instead. Something like "encrypt user
password" or "sign API response" or "hash PII". The engine looks up the current
algorithm and parameters for that purpose from the policy service.
Self-describing agility envelope
The output is wrapped in a structured envelope at creation time. It encodes the algorithm identifier · version · key size · mode · padding · IV · salt · iteration count. The envelope is decoded to reverse the operation correctly at consumption time. So data from an old algorithm stays decryptable and verifiable after a switch.
Enforcement modes
Policy runs in one of three modes. STRICT rejects non-conformant algorithm requests. WARN allows them but flags the violation. OFF just observes. Weak legacy requests can also be upgraded automatically to a hardened baseline.
Delegate providers do the math
The engine registers as a Security Provider in Java. First it resolves the algorithm. Then it hands the operation to an underlying provider such as SunJCE or BouncyCastle. Calls outside the managed purposes 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. That
// works 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. MyPQC pairs that with consumption-time decoding. That keeps historical data usable through every transition.
Crypto agility: the creation phase
Governs encryption · signing · hashing · key derivation. It intercepts the operation and applies the policy-mandated algorithm. It writes the agility envelope too. Every output is self-describing from the moment it's produced.
Cipher agility: the consumption phase
Governs decryption · verification · parsing. It reads the envelope and picks the right algorithm and parameters automatically. Legacy data from before deployment falls back to configurable rules. Tampered or unsupported envelopes fail safely.
Every language
One policy for wherever your code runs
The purpose-based API is not tied to one language. The same central policy governs any estate. Mobile apps and backends and admin portals all migrate on the same schedule. One policy. Not three separate projects.
Mobile
We have the Dart/Flutter SDK for mobile and cross-platform apps. A phone signing a request follows the same policy as the backend that verifies it.
Backend & security integration
We have a standard Security Provider for a Java backend. Register it once. Existing
Cipher.getInstance()
and
Signature.getInstance()
calls become policy-governed. No rewrite of surrounding code.
Web & admin portals
We have a library integration for a PHP application or admin portal. It resolves the same purposes against the same policy service as everything else in the estate.
Every output carries the same self-describing envelope. It doesn't matter which language made it. A signature made on mobile decodes correctly on the backend. The algorithm identity travels with the bytes. No config file for each side to keep in sync. An automated cross-language test suite checks this on every build. Not just the documentation.
Where the agility actually happens
Cryptography changes where it's created and not just where it crosses the network
Several crypto-agility approaches only intercept network traffic. A proxy or gateway renegotiates TLS in flight. That secures a connection in transit. It says nothing about password hashing before storage or database columns encrypted at rest or a mobile app signing a request before it reaches the network.
Nothing to rack or patch or scale. The engine runs inside the application as a language-native provider or library. It is not a box in the network path.
No added network hop. No extra latency. No new device on the network for an attacker to target.
Governs cryptography wherever it actually executes. That includes password hashing. File encryption. Database columns. API signing. It reaches the same depth MCert maps. That runs from the network down to the hardware root of trust.
Capabilities
Built for governed and enterprise-scale cryptographic change
Everything a CISO needs to see and control and prove the cryptographic posture of the estate. Any language. One control plane.
Drop-in JCE integration
A custom Java Security Provider intercepts standard getInstance() calls. Existing crypto code becomes policy-governed with minimal refactoring.
Scheduled transitions
Define an algorithm cutover with an effective date. Say AES-128-CBC moves to AES-256-GCM on a set date. Every connected system switches automatically.
Self-describing envelope
Deterministic and versioned and HMAC-protected metadata travels with each output. That removes fragile per-application parameter handling.
Cryptographic inventory
A live dashboard shows every registered purpose. It shows the current algorithm mapping. It shows transition history and connected systems.
Tamper-evident audit
RBAC and MFA on policy changes. An exportable audit trail (PDF / CSV) records who changed what and when.
Backward compatibility
Historical ciphertext and signatures keep decrypting and verifying with no application-side change. This holds 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. Engines keep operating.
PQC-ready
Extends to the NIST PQC families. ML-KEM (FIPS 203) and ML-DSA (FIPS 204) and SLH-DSA (FIPS 205). Post-quantum migration becomes a policy change.
Protocol flexibility
The client selects its transport (gRPC or Dubbo Triple or REST/JSON) as configuration only. No cryptographic code to touch.
Governed algorithm releases
An algorithm must pass a formal release process before policy can resolve to it. It gets schema-checked and tested against known vectors and recorded in a tamper-evident record. Policy can propose a change. It cannot make an unproven algorithm available.
Use cases
What crypto-agility lets you do
Bank or agency migrating RSA → ML-DSA
Move signing purposes from RSA to the NIST-standardized ML-DSA (FIPS 204). Do it centrally and on a schedule. No re-engineering of 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. The inventory dashboard proves the baseline is actually in force.
National algorithm selection
Select a Malaysian scheme where local policy calls for it. KAZ-SIGN handles signing. KAZ-KEM handles key establishment. Both are optional. They're offered alongside the NIST standards. The choice is policy-driven. You can switch back to a NIST algorithm at any time. National choice without lock-in.
Your own national algorithms on your terms
KAZ-SIGN and KAZ-KEM are Malaysian post-quantum algorithms for signing and key establishment. MyPQC offers both alongside the NIST standards (ML-DSA · SLH-DSA · ML-KEM). That cuts dependence on foreign standards and keeps a locally developed option under your control. Neither is a NIST standard. You select either by policy.
Crypto-agility makes this practical. Choosing a national algorithm is a policy decision. You can change it at any time. You stay connected to the NIST algorithms whenever you want.
Standards & algorithms
Aligned with the standards and agile about the choice
The engine works through the standard JCE API. It covers the major operation categories. Policy-driven agility spans 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) · KAZ-KEM (optional national) |
| Digital signatures | RSA · ECDSA · EdDSA | ML-DSA (FIPS 204) · SLH-DSA (FIPS 205) · KAZ-SIGN (optional national) |
| 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 instead of a code project
See how the Crypto Agility Core Engine lets you migrate to post-quantum standards across any language. No re-engineering applications.