Post-Quantum Cryptography Explained: Why Today's Encryption Needs an Upgrade

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.

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:

1. Capture encrypted network traffic today.
2. Store the captured data for years.
3. Wait for cryptographic capabilities to improve.
4. 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

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.

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.

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:

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:

1. Cryptography fundamentals: AES, RSA, ECC, ECDH, digital signatures, hashes, KDFs.
2. TLS fundamentals: handshake, certificates, trust chain, session keys, TLS 1.3.
3. Quantum threat basics: Shor's algorithm, Grover's algorithm, HNDL.
4. PQC standards: ML-KEM, ML-DSA, SLH-DSA.
5. KEM concepts: encapsulation, decapsulation, shared secrets.
6. Hybrid key exchange: classical and PQ components in a protocol.
7. Hands-on experiment: benchmark a vetted ML-KEM implementation on Android.
8. Protocol integration: study supported hybrid TLS implementations and interoperability.
9. 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.