Imagine encrypting sensitive data today—and discovering years later that someone can decrypt it because quantum computers have become powerful enough.
That is the long-term concern behind Post-Quantum Cryptography (PQC).
PQC is not science fiction, and it does not mean quantum computers are already breaking modern encryption. It is a practical cryptographic migration effort: designing and deploying algorithms that are expected to remain secure against both classical computers and sufficiently capable quantum computers.
In this article, we will understand:
- What quantum computers could threaten
- Why RSA and ECC are at risk
- What “harvest now, decrypt later” means
- How PQC works at a high level
- The NIST-standardized algorithms
- How hybrid key exchange works
- What Android and backend developers should do
- A practical migration checklist
Important: PQC algorithms are designed to resist known quantum attacks. No cryptographic system is guaranteed to be secure forever; implementation quality, protocol design, key management, and future cryptanalysis still matter.
1. What Is Post-Quantum Cryptography?
Post-Quantum Cryptography (PQC), also called quantum-resistant cryptography, refers to cryptographic algorithms designed to run on conventional computers while resisting attacks from both classical and quantum computers.
That distinction is important:
- Quantum cryptography often refers to techniques that use quantum physics, such as quantum key distribution.
- Post-quantum cryptography uses mathematical algorithms on ordinary devices—phones, servers, laptops, and embedded systems.
PQC does not require an Android phone to contain a quantum processor. A mobile app can use a PQC library on today's hardware, subject to library and platform support.
2. Why Are Quantum Computers a Cryptographic Concern?
Many widely used public-key systems rely on mathematical problems that are difficult for classical computers.
Examples include:
- RSA: integer factorization
- Diffie–Hellman: discrete logarithm
- Elliptic Curve Diffie–Hellman (ECDH): elliptic-curve discrete logarithm
- ECDSA: elliptic-curve discrete logarithm
A sufficiently capable, fault-tolerant quantum computer running Shor's algorithm could solve the underlying problems efficiently enough to undermine RSA and elliptic-curve cryptography.
This does not mean a quantum computer can instantly break every encryption algorithm.
What about AES and SHA-256?
Symmetric encryption and hash functions face a different quantum threat.
Grover's algorithm can provide a theoretical quadratic speedup for brute-force search. It does not simply make AES or SHA-256 useless.
A common mitigation is to use larger security parameters where appropriate. For example, AES-256 is generally considered a strong choice for long-term symmetric security, although complete system security depends on much more than the algorithm name.
| Cryptographic system | Quantum concern | General direction |
|---|---|---|
| RSA | Shor's algorithm threatens its mathematical foundation | Replace with quantum-resistant public-key algorithms |
| ECDH / ECDSA | Shor's algorithm threatens elliptic-curve security | Migrate key establishment and signatures |
| AES | Grover may reduce effective brute-force security | Use suitable key sizes, such as AES-256 |
| SHA-256 | Grover affects generic preimage search | Consider security margins and appropriate hash choices |
3. The “Harvest Now, Decrypt Later” Threat
This is one of the strongest reasons to plan PQC migration before a large quantum computer exists.
An attacker could:
- Capture encrypted network traffic today.
- Store the captured data for years.
- Wait for cryptographic capabilities to improve.
- Attempt to decrypt the old traffic later.
This strategy is commonly called Harvest Now, Decrypt Later (HNDL).
It matters most when information remains sensitive for a long time, such as:
- Government or defense communications
- Healthcare and patient records
- Financial information
- Intellectual property
- Private messages
- Long-lived business secrets
Example
Suppose a company encrypts a confidential document in 2026 using a key exchange that is vulnerable to a future quantum attack.
2026: Attacker captures encrypted traffic
|
v
2027–2035: Traffic remains stored
|
v
Future: A sufficiently capable quantum computer becomes available
|
v
Attacker attempts to recover the historical session keys
|
v
Previously captured data may become readable
The risk depends on the encryption protocol, whether the attacker captured the necessary key-exchange information, the implementation, and future computing capabilities. It is not a guarantee that every recorded connection can be decrypted.
Takeaway: Security planning must consider how long data needs to remain confidential—not only whether it is safe today.
4. What Algorithms Are Being Standardized?
The U.S. National Institute of Standards and Technology (NIST) has standardized key-establishment and digital-signature algorithms for post-quantum use.
The first major standards were finalized in 2024.
NIST PQC standards
| Standard | Algorithm | Primary purpose |
|---|---|---|
| FIPS 203 | ML-KEM | Key encapsulation / establishing a shared secret |
| FIPS 204 | ML-DSA | Digital signatures |
| FIPS 205 | SLH-DSA | Hash-based digital signatures |
These standards are based on different mathematical constructions and have different performance and size characteristics.
ML-KEM (formerly Kyber)
ML-KEM is a Key Encapsulation Mechanism (KEM).
A KEM helps two parties establish a shared secret over a public channel. That shared secret can then be used with symmetric encryption.
A simplified flow:
Server generates:
KEM public key + private key
|
v
Client receives public key
|
v
Client encapsulates:
shared secret + ciphertext
|
v
Client sends KEM ciphertext to server
|
v
Server decapsulates using private key
|
v
Both parties derive the same shared secret
|
v
Use a symmetric cipher for application data
ML-KEM does not directly encrypt an arbitrary document or replace AES. It establishes a shared secret that can be used in a secure protocol.
ML-DSA (formerly Dilithium)
ML-DSA is a post-quantum digital signature algorithm.
It can be used to:
- Sign software releases
- Verify signed messages
- Authenticate artifacts
- Support certificate and protocol designs
A signature proves authenticity and integrity under the relevant public-key trust model. It does not encrypt the signed content.
SLH-DSA (formerly SPHINCS+)
SLH-DSA is another post-quantum signature standard, based on hash functions.
It offers a different security construction from ML-DSA, with trade-offs such as larger signatures and different performance characteristics.
5. KEM vs Encryption vs Digital Signature
These terms are often confused.
| Concept | What it does |
|---|---|
| Encryption | Protects data confidentiality |
| Decryption | Recovers protected data |
| KEM | Establishes a shared secret between parties |
| Key derivation function (KDF) | Derives keys from secret material |
| Digital signature | Provides authenticity and integrity |
| Hash | Produces a fixed-length digest |
A typical secure connection combines multiple primitives:
Key Exchange / KEM
|
v
Shared Secret
|
v
KDF
|
v
Symmetric Session Keys
|
v
Authenticated Encryption (AEAD)
|
v
Encrypted Application Data
This architecture is still relevant in a post-quantum system. PQC changes the public-key components; symmetric encryption and protocol protections remain essential.
6. What Is Hybrid Key Exchange?
During migration, systems may combine a traditional key exchange with a post-quantum KEM.
For example, a TLS deployment might combine:
- A classical ECDH component
- A post-quantum ML-KEM component
The protocol derives a session secret from both components according to its specified construction.
Conceptually:
Classical ECDH shared secret ─────┐
├──> Secure key derivation
ML-KEM shared secret ────────────┘ |
v
Session traffic keys
|
v
Encrypted TLS traffic
The goal is to maintain security if one component remains secure, under the protocol's assumptions and correct implementation.
Hybrid does not mean manually concatenating secrets in application code. Use a protocol and implementation that define the combination, transcript binding, authentication, and key derivation correctly.
7. Does PQC Replace TLS, HTTPS, or AES?
No.
PQC is an upgrade to cryptographic components—not a replacement for the entire security stack.
| Existing technology | PQC migration perspective |
|---|---|
| HTTPS | Still the application security model; TLS implementations may adopt PQ key exchange |
| TLS | Protocol remains; cipher suites and key-exchange mechanisms evolve |
| AES-GCM | Continues to protect bulk data |
| RSA certificates | May need migration to quantum-resistant signatures when supported by ecosystem and PKI |
| ECDH | May be replaced or combined with PQ KEMs for key establishment |
| Certificate validation | Still required |
| Secure key storage | Still required |
| Authentication and authorization | Still required |
A connection can use a post-quantum key exchange and still be insecure if certificate validation is disabled, keys are exposed, or the backend accepts unauthorized requests.
8. Android Developer Perspective: Where Does PQC Fit?
For Android developers, the practical question is not “Should I implement ML-KEM in every app?”
It is:
Which cryptographic layer does my application control, and which layer belongs to the platform, library, or backend?
Typical Android application architecture
Android App
|
| HTTPS request
v
OkHttp / Retrofit
|
v
Android TLS Provider
|
v
TLS Key Exchange + Authentication
|
v
Backend Server
In most applications:
- Retrofit handles HTTP API definitions.
- OkHttp handles HTTP networking.
- Android's TLS provider performs TLS cryptographic operations.
- The backend and infrastructure configure TLS support.
- The application validates server identity through the TLS trust model.
PQC support may require coordinated changes in the TLS provider, networking library, server, load balancer, and certificate ecosystem.
Important Android guidance
Do not assume that adding an ML-KEM dependency automatically makes all Retrofit traffic quantum-resistant.
A standalone PQC library can perform cryptographic operations, but it does not automatically integrate with Android's TLS stack.
For production networking, use supported platform or networking implementations that explicitly document PQ/hybrid TLS capabilities.
9. Example: A Traditional HTTPS Request vs PQ-Enabled TLS
Traditional connection (simplified)
Android App
|
| HTTPS
v
TLS handshake
|
| Classical key exchange
v
Session key derivation
|
v
Encrypted API request
Hybrid post-quantum connection (simplified)
Android App
|
| HTTPS
v
TLS handshake
|
| Classical + PQ key exchange
v
Combined secret derivation
|
v
Session key derivation
|
v
Encrypted API request
The Retrofit API call can remain the same:
interface UserApi {
@GET("v1/profile")
suspend fun getProfile(): UserProfile
}
The key-exchange behavior is generally configured below the API interface, in the TLS/networking implementation.
10. Can I Use PQC Directly in Kotlin?
Yes, with an appropriate cryptographic library and a clearly defined use case.
Possible use cases include:
- Experimental ML-KEM key establishment
- Post-quantum signature verification
- Secure file-encryption research
- Interoperability testing
- Building a cryptographic proof of concept
However, production cryptography should not be assembled from low-level primitives without protocol expertise and security review.
Illustrative KEM workflow
The following is conceptual pseudocode—not a drop-in API from a particular library:
// Conceptual only: actual APIs depend on the selected PQC library.
val serverPublicKey = receiveServerKemPublicKey()
val encapsulation = mlKem.encapsulate(serverPublicKey)
val sharedSecret = encapsulation.sharedSecret
val kemCiphertext = encapsulation.ciphertext
sendToServer(kemCiphertext)
// Both parties derive traffic keys using a specified KDF.
// Never use the raw shared secret directly as an application key.
val trafficKey = kdf(sharedSecret, context = "application-session")
The server decapsulates the ciphertext using its private key and derives the corresponding secret.
A real design must also authenticate the public key, bind it to the intended identity, prevent replay and downgrade attacks, and define key rotation and failure handling.
11. PQC and Mobile Performance
Post-quantum algorithms can have different performance and resource characteristics from classical cryptography.
For mobile applications, evaluate:
- Key and ciphertext sizes
- Signature sizes
- CPU usage
- Memory allocation
- Battery impact
- Network overhead
- Handshake latency
- Compatibility with older devices
- Native library packaging and ABI support
- Side-channel resistance
- Secure key lifecycle
A larger handshake can affect mobile networks more than a desktop connection, especially when latency is high.
What should you benchmark?
For an Android proof of concept, measure:
| Metric | Why it matters |
|---|---|
| Key generation time | Setup cost |
| Encapsulation time | Client-side KEM cost |
| Decapsulation time | Server-side KEM cost |
| Public key size | Provisioning and storage overhead |
| Ciphertext size | Network transfer overhead |
| Signature size | Signed artifact/message overhead |
| Memory usage | Mobile resource constraints |
| End-to-end handshake latency | Actual user experience |
Benchmark on real devices, not only on an emulator.
12. PQC Migration Strategy for Organizations
A migration should start with cryptographic inventory—not an immediate algorithm replacement.
Step 1: Inventory cryptography
Identify where your organization uses:
- RSA
- ECDSA
- ECDH
- TLS
- VPNs
- SSH
- Certificate authorities
- Code signing
- Firmware signing
- Encrypted backups
- Long-term data encryption
Document algorithm, key size, owner, dependency, data lifetime, and upgrade constraints.
Step 2: Identify long-lived sensitive data
Ask:
- How long must this information remain confidential?
- Could an attacker capture it today?
- Would future decryption create business, legal, or privacy impact?
- Which systems cannot be upgraded quickly?
Prioritize data with long confidentiality requirements.
Step 3: Check vendor and platform support
Confirm PQC support with:
- TLS libraries
- Reverse proxies and load balancers
- Cloud providers
- VPN providers
- Operating systems
- HSMs and key-management services
- Certificate and signing infrastructure
Avoid assuming that a product supports a standard merely because it supports a generic cryptographic API.
Step 4: Run interoperability tests
Test both endpoints and the complete network path.
Verify:
- Handshake success
- Authentication
- Downgrade behavior
- Failure handling
- Network middlebox compatibility
- Performance on mobile and constrained networks
Step 5: Deploy gradually
Use controlled rollout and monitoring.
Track:
- Handshake failures
- Latency
- CPU usage
- Memory
- Compatibility issues
- Security alerts
Have a documented rollback strategy that does not silently downgrade security.
13. Common PQC Misconceptions
“Quantum computers can break AES instantly.”
False. Grover's algorithm gives a theoretical quadratic speedup for brute-force search. AES-256 remains a strong symmetric encryption choice.
“PQC means using a quantum computer.”
False. PQC algorithms run on conventional computers.
“ML-KEM encrypts my complete API response.”
False. ML-KEM establishes a shared secret. Symmetric encryption protects application data.
“Adding a PQC library makes Retrofit quantum-safe.”
False. The library must be integrated into the relevant protocol and networking layer.
“We can wait until quantum computers are available.”
Risky. Sensitive data captured today may remain valuable in the future, and infrastructure migrations take time.
“Post-quantum means future-proof forever.”
False. Cryptographic standards can be revised or replaced as research evolves.
14. Practical Checklist for Android and Backend Teams
- [ ] Inventory public-key algorithms used by the application and backend.
- [ ] Confirm which TLS provider and networking stack are in use.
- [ ] Check official vendor support for PQ/hybrid TLS.
- [ ] Prioritize long-lived sensitive data.
- [ ] Keep certificate validation enabled.
- [ ] Avoid custom cryptographic protocol implementations.
- [ ] Use established KDFs and authenticated encryption.
- [ ] Protect private keys using appropriate key-management mechanisms.
- [ ] Test handshake size and latency on mobile networks.
- [ ] Verify downgrade and compatibility behavior.
- [ ] Document migration and rollback plans.
- [ ] Track NIST and platform updates.
15. Learning Roadmap: How to Learn PQC
If you are an Android developer learning mobile security, follow this order:
- Cryptography fundamentals: AES, RSA, ECC, ECDH, digital signatures, hashes, KDFs.
- TLS fundamentals: handshake, certificates, trust chain, session keys, TLS 1.3.
- Quantum threat basics: Shor's algorithm, Grover's algorithm, HNDL.
- PQC standards: ML-KEM, ML-DSA, SLH-DSA.
- KEM concepts: encapsulation, decapsulation, shared secrets.
- Hybrid key exchange: classical and PQ components in a protocol.
- Hands-on experiment: benchmark a vetted ML-KEM implementation on Android.
- Protocol integration: study supported hybrid TLS implementations and interoperability.
- Production migration: inventory, risk assessment, testing, rollout.
This path helps you understand both the mathematics and the real-world engineering impact.
Conclusion
Post-Quantum Cryptography is not a replacement for every cryptographic component. It is a transition toward public-key algorithms designed to withstand future quantum attacks.
The most important actions today are to understand the threat, identify long-lived sensitive data, inventory cryptographic dependencies, and plan a standards-based migration.
For Android developers, PQC is especially interesting at the TLS, secure communication, software-signing, and mobile-security layers. The safest path is to learn the primitives, experiment with vetted implementations, and rely on properly integrated protocols for production systems.
References
- NIST Post-Quantum Cryptography
- NIST FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)
- NIST FIPS 204 — Module-Lattice-Based Digital Signature Standard (ML-DSA)
- NIST FIPS 205 — Stateless Hash-Based Digital Signature Standard (SLH-DSA)
- NIST — Transition to Post-Quantum Cryptography
- Android Developers — Security
- OWASP Mobile Application Security
- IETF TLS Working Group
Have you started exploring Post-Quantum Cryptography in Android or backend systems? Share your learning experience in the comments.
Top comments (0)