Prompt and context
A company has mobile, web, device, and third-party API clients that still use RSA or elliptic-curve cryptography. Design a migration plan to post-quantum cryptography and explain compatibility, performance, key rotation, and rollback.
NIST has published FIPS 203, 204, and 205 for ML-KEM, ML-DSA, and SLH-DSA. The interview is not a naming exercise: it tests whether you can turn long-term confidentiality, client lifecycles, and operational risk into staged decisions. An IETF hybrid TLS draft is still a draft, so it is not a universal compatibility promise.
What the interviewer is testing
The interviewer wants to see an inventory of real cryptographic assets, a distinction between key establishment and signatures, an explanation of harvest-now-decrypt-later risk, a design for crypto agility, and measurable gates for compatibility, failure rate, and performance. You should also identify decisions that require security, compliance, vendor, and product review.
Questions to clarify first
- Which data must remain confidential for ten years or longer, and which signatures need long-term verification?
- How are client versions, firmware upgrade paths, offline periods, and third-party dependencies distributed?
- Where are RSA, ECDH, and ECDSA call sites, certificate chains, HSMs, and backups?
- Do transport, data-at-rest, code-signing, and token-signing keys have separate lifecycles?
- What are the budgets for handshake latency, message size, CPU, memory, and failure rate?
- Can an old algorithm remain for a bounded window, and who approves downgrade and emergency rollback?
A 30-second answer
“I would inventory cryptographic assets and confidentiality lifetimes first, then rank them by exposure, replacement difficulty, and client updatability. I would separate key establishment from signatures and use versioned algorithm suites with capability detection for classical, post-quantum, or hybrid modes; silent downgrade would be disallowed. I would canary controllable services and new clients while measuring handshake success, response size, CPU, fallback, and key-rotation metrics. I would expand only after compatibility, performance, audit, and rollback gates pass, while retaining old verification keys without issuing new old-format credentials.”
Step-by-step deep answer
Step 1: Inventory algorithms and data lifetimes
Scan TLS, VPN, service-to-service RPC, database encryption, backups, signatures, certificates, firmware, and vendor SDK call sites. For each asset record the algorithm, key size, purpose, owner, rotation method, client versions, and confidentiality lifetime. Prioritize traffic that may be collected now and needs long-term secrecy, then signatures that must be verified for many years.
Step 2: Create risk tiers and a target baseline
Score asset criticality, attack feasibility, migration windows, unupdatable-client share, and replacement cost. The baseline should state which new connections require post-quantum or hybrid protection and which old connections may continue only in an approved, short, monitored compatibility window. Do not make the date of a practical quantum computer the only decision variable.
Step 3: Turn cryptography into a replaceable capability
Keep business code independent from crypto libraries through versioned algorithm suites, key types, and certificate policy. The server may evaluate a capability declaration, but clients must not choose weak algorithms; a policy service should pause a suite, switch providers, and record scope. Ciphertext and signature metadata should carry a version so historical formats remain identifiable.
Step 4: Choose key-establishment and signature paths
ML-KEM is for key encapsulation, while ML-DSA and SLH-DSA are signature standards; their keys, certificates, and performance differ. For TLS, evaluate a classical plus ML-KEM hybrid handshake only after checking implementation, draft status, gateway, and endpoint support. Validate certificate-chain size, verification cost, and archival requirements separately for signatures.
Step 5: Define compatibility and rollback boundaries
Let new clients select a suite through capability detection and place old clients in an explicit compatibility pool. Downgrade must be observable, time-bounded, and approved per tenant or device; a failed handshake must not trigger unlimited fallback. Rollback should withdraw the new traffic entry point without deleting old public keys still needed for verification. Record the reason, scope, and re-enable criteria.
Step 6: Measure cost with canary experiments
Test connection success, handshake latency, message size, CPU, memory, bandwidth, certificate caching, and HSM throughput on internal services, updatable mobile clients, and low-risk tenants. Load-test peaks, weak networks, offline recovery, and multiple regions. Compare post-quantum overhead with business SLOs; respond by version and client type instead of disabling security policy globally.
Step 7: Coordinate keys, vendors, and audit
Define generation, custody, rotation, revocation, backup, and destruction windows for new and old keys. Verify target-format support in HSMs, cloud KMSs, certificate authorities, proxies, and third-party SDKs; record suite changes as audit events. Security owns policy, platform owns implementation, and legal or compliance confirms applicable retention and evidence requirements.
Step 8: Set release gates and a long-term exit
Release gates should include compatibility success, performance budget, old-algorithm traffic share, abnormal fallback, rotation success, and audit completeness. Give every stage a stop line and owner. Once old-format traffic is below its threshold, stop issuing new old credentials, then revoke acceptance after a verification window. Keep migration records so the next algorithm replacement starts with evidence.
Trade-offs and boundaries
Hybrid versus pure post-quantum mode
Hybrid mode reduces dependence on one new algorithm but increases handshake size, implementation complexity, and negotiation testing. Pure post-quantum mode expresses the target more directly but may exclude unupgradable clients. Let the compatibility matrix and risk gates decide.
Security strength versus performance budget
Larger keys, ciphertexts, or signatures affect MTU, handshakes, caches, and HSM throughput. Measure real traffic and reserve margin for mobile networks, device CPUs, and peak concurrency. Performance tuning must not be achieved through silent downgrade.
Rollback versus retaining old keys
The rollback entry point and key destruction are separate decisions. Old public keys may still be required for historical signatures, so a rollback should not immediately delete them. Stop new issuance, restrict new connections, retain read-only verification, and destroy only when evidence is sufficient.
Failure drills and evolution plan
An old device cannot be upgraded
Build a device-version inventory, an isolated gateway, and an explicit expiry date. Verify that isolation prevents the weak suite from spreading to new clients, and give owners an upgrade or replacement path.
A larger handshake breaks connections
Test fragmentation, MTU, timeouts, and retries through real proxies, load balancers, and mobile networks. If the new suite fails, return to the approved compatibility pool and alert; the client must not try additional weak suites on its own.
A vendor supports only old signatures
Give the vendor a versioned interface and transition certificate, with limited lifetime and permissions for old signatures. Put the upgrade commitment into the contract and acceptance metrics instead of hiding an uncontrolled dependency in “later work.”
Common mistakes and follow-ups
Mistake 1: Treating algorithm replacement as one configuration release
Follow-up: How do you find every crypto call site, backup, and offline device? A strong answer names an asset inventory, dependency graph, and owner.
Mistake 2: Treating FIPS publication as universal client support
Follow-up: Where is support evidenced for the target library, certificate authority, HSM, gateway, and browser? Separate a finished standard from a usable product implementation.
Mistake 3: Silently falling back to RSA
Follow-up: Who approves downgrade, how long does it last, how is it alerted, and what ends it? Give an auditable compatibility window.
Mistake 4: Measuring only average latency
Follow-up: How do you test peak concurrency, weak networks, packet size, CPU, memory, and certificate caching? Describe layered load tests and stop lines.
Follow-up questions and responses
Why migrate key establishment and signatures separately?
Key establishment protects session confidentiality; signatures protect identity and integrity. Their algorithms, certificate chains, key sizes, and verification lifetimes differ, so separate canaries avoid blocking every workload on one replacement.
How do you prove crypto agility?
Show versioned suites, policy switching, key metadata, provider replacement, a compatibility matrix, audit events, and rollback drills. Editing one configuration file does not prove that business code, certificates, and device paths are replaceable.
When can you stop accepting an old algorithm?
After new-client coverage, connection success, performance, and audit gates pass, old traffic is attributed, and owners complete upgrades, stop new issuance first. After a read-only verification window, revoke acceptance. Each step needs a rollback condition and an owner.