Hybrid Post-Quantum Cryptography for Microservices (Part 2)

In Part 1, we walked through how a quantum-capable adversary harvests, breaks, and exploits microservice traffic. Now we show how to stop it.

Hybrid Post-Quantum Cryptography at the Service Level

The solution is to add quantum-resistant encryption at the application layer, between your services, using algorithms that no known quantum algorithm can efficiently solve.

We built a production-ready Go microservice that does exactly this. It sits alongside your application and provides hybrid post-quantum cryptography through a Unix socket. No network exposure. No cloud dependency. Your application sends plaintext in, gets quantum-safe ciphertext out.

The word "hybrid" is important. Every operation uses two algorithm families simultaneously:

An attacker must break both the classical and post-quantum algorithms to compromise your data. If quantum computers break X25519, ML-KEM-1024 protects you. If a flaw is discovered in ML-KEM-1024, X25519 still holds. Both must fail simultaneously.

ML-KEM and ML-DSA are the algorithms NIST approved in 2024 after years of public cryptanalysis. They are not experimental. They are the standard.

How It Works in Practice

The microservice communicates with your application through a Unix socket. This is a deliberate architectural choice. Unix sockets are local-only. There is no TCP port to scan, no network interface to attack, no TLS certificate to manage for the crypto service itself.

Here is what the integration looks like for a PHP application:

// Connect to the PQ crypto microservice via Unix socket
$client = new PQCryptoClient($socketPath, $authToken);

// Encrypt sensitive data before it leaves your service
$encrypted = $client->kemEncrypt('service-key-id', $sensitivePayload);

// The encrypted data can now safely transit your network
// Even if captured, no known quantum algorithm can efficiently decrypt this

// On the receiving end, decrypt with the corresponding key
$decrypted = $client->kemDecrypt(
    'service-key-id',
    $encrypted['kem_ciphertext'],
    $encrypted['ciphertext']
);

The microservice handles all cryptographic operations. Your application code never touches private keys. Key material is stored in memory-locked (mlock'd) regions that cannot be swapped to disk.

Binding Encryption to Context

Every encryption operation supports Additional Authenticated Data (AAD). This binds the ciphertext to a specific context:

$aad = "user:42:session:abc123";
$encrypted = $client->kemEncrypt('key-id', $payload, $aad);

// Decryption fails if the AAD does not match
// An attacker cannot replay this ciphertext in a different context
$decrypted = $client->kemDecrypt('key-id', $kem_ct, $ct, $aad);

If an attacker captures the ciphertext and tries to replay it in a different context, different user, different session, decryption fails. The cryptography enforces that the data is only valid where it was intended to be used.

Verifiable Dual Signatures

Every signature operation produces and verifies both classical and post-quantum signatures independently:

$result = $client->verify('key-id', $message, $signature);
// Returns:
// 'valid' => true,         // Both signatures verified
// 'classic_valid' => true, // Ed25519 signature verified
// 'quantum_valid' => true, // ML-DSA-87 signature verified
// 'algorithm' => 'Ed25519-ML-DSA-87'

You can audit each algorithm independently. If either signature fails, the overall verification fails. This is defense in depth that you can observe and measure.

Running the Attack Scenario Again

In Part 1, we walked through a three-stage quantum attack: harvest, break, exploit. Let us replay it against an architecture using hybrid post-quantum cryptography.

Stage 1: Harvest. The attacker captures encrypted traffic between your services. This time, the key encapsulation used X25519 combined with ML-KEM-1024. The digital signatures used Ed25519 combined with ML-DSA-87.

Stage 2: Break (attempted). The quantum computer runs Shor's algorithm against the captured key exchange. It breaks the X25519 component. But the ML-KEM-1024 component is based on a lattice problem that no known quantum algorithm, including Shor's, can efficiently solve. The attacker has half of a hybrid key. Half of a key is no key at all.

Stage 3: Exploit (failed). Without both components of the hybrid key exchange, the session keys cannot be recovered. The encrypted traffic remains encrypted. The credentials, tokens, and sensitive data captured in Stage 1 are still protected.

The harvest-now-decrypt-later strategy fails because there is no "later" in which both algorithm families are broken simultaneously.

What the Tests Prove

The microservice ships with a comprehensive test suite that validates every cryptographic operation:

=== PQ Crypto Microservice Test Suite ===

 1. Health Check - ✓ PASSED
 2. Service Info - ✓ PASSED
 3. KEM Key Generation - ✓ PASSED
 4. KEM Encryption/Decryption - ✓ PASSED
 5. KEM with AAD - ✓ PASSED
 6. KEM Get Public Key - ✓ PASSED
 7. Sign Key Generation - ✓ PASSED
 8. Sign and Verify - ✓ PASSED
 9. Signature Tampering Detection - ✓ PASSED
10. External Public Key Verification - ✓ PASSED

All tests passed! Hybrid post-quantum cryptography is working correctly.

Test 9 is particularly important. It verifies that tampered signatures are correctly rejected. The system does not just encrypt. It detects manipulation.

These are not mock tests. They execute real hybrid post-quantum cryptographic operations using the Cloudflare CIRCL library's implementation of ML-KEM-1024 and ML-DSA-87. The same algorithms, the same key sizes, the same security level that protects your production data.

Multi-Node Mesh Architecture

For organizations running distributed infrastructure, the microservice supports a mesh architecture where multiple nodes maintain cryptographic identities and distribute keys securely.

Each node holds four keypairs: Ed25519 and ML-DSA-87 for signing, X25519 and ML-KEM-1024 for key encapsulation. Key distribution uses a binary SecureKeyEnvelope protocol with replay prevention (15-minute message ID cache) and version rollback protection. An attacker cannot replay an older key version to force a downgrade.

Keys are distributed through the mesh with dual signatures. Both the classical and post-quantum signatures must verify for a node to accept a key update. A compromised signature algorithm does not compromise the key distribution.

The Window Is Open Now

The three-stage attack described in this series is not speculative. Stage 1 is happening today. Stages 2 and 3 are a matter of time.

Every day your microservices communicate using quantum-vulnerable cryptography, you are adding to the archive an attacker will eventually decrypt. The data captured today will be just as readable in 2035 as the data captured tomorrow.

Hybrid post-quantum cryptography closes this window. It protects your current traffic against future quantum capabilities while maintaining classical security against today's threats. And it does this at the service level, where your most sensitive data actually moves.

The implementation exists. The algorithms are NIST-approved. The tests pass. The question is whether you deploy protection before or after the harvest.

This post is part of Scramble Technology's series on practical post-quantum security. Read Part 1 for the full threat scenario, or see our previous post on why traditional password managers are not quantum safe.

Interested in evaluating hybrid post-quantum cryptography for your microservice architecture? Contact Scramble Technology to discuss your deployment requirements.