Quantum-Safe Cloud -- Part 1

Why Your Encryption Has an Expiry Date

#security #post-quantum #cryptography #quantumapi

The Problem

Your database is encrypted. Your API uses HTTPS. Your secrets are in Key Vault. You’re doing it right.

But here’s something most developers don’t know: the encryption protecting that data has an expiry date. Not because of a software bug. Because of physics.

In August 2024, NIST published the first three post-quantum cryptographic standards. These are replacements for RSA and elliptic curve cryptography — the algorithms protecting almost all secure communication on the internet today. NIST doesn’t publish emergency standards unless there’s a reason. The reason is quantum computers.

A sufficiently powerful quantum computer running Shor’s algorithm can break RSA-2048 and ECC in hours. Not years. Hours. The same keys protecting your HTTPS traffic, your JWT tokens, your database encryption.

“But quantum computers aren’t powerful enough yet.” That’s true. The most advanced ones today can’t break production cryptography. The estimates vary — some say 5 years, some say 15. Nobody knows exactly. But here’s the part that changes the calculation:

Harvest now, decrypt later.

Attackers don’t need a quantum computer today. They just need to record your encrypted traffic today and decrypt it later when the computers catch up. Intelligence agencies, organised crime groups, and nation-state actors are already doing this. If your data has value beyond the next 5-10 years — financial records, health data, government communications, intellectual property — it’s already at risk.

And for regulated industries, the deadline isn’t “when quantum computers arrive.” The compliance deadline is now. NIST’s migration guidance and EU regulations under eIDAS 2.0 are already requiring post-quantum readiness. NIS2 auditors are asking questions about cryptographic agility.

The expiry date on your encryption is real. The question is what you do about it before it expires.

The Solution

Post-quantum cryptography (PQC) replaces RSA and ECC with algorithms that are hard to break even for quantum computers. They’re based on different mathematical problems — lattices, hash functions — that Shor’s algorithm can’t exploit.

NIST standardised three algorithms in August 2024:

  • ML-KEM (FIPS 203, based on CRYSTALS-Kyber) — for key encapsulation. Replaces RSA key exchange and ECDH.
  • ML-DSA (FIPS 204, based on CRYSTALS-Dilithium) — for digital signatures. Replaces RSA signatures and ECDSA.
  • SLH-DSA (FIPS 205, based on SPHINCS+) — an alternative signature scheme based on hash functions.

These aren’t experimental. They’re published standards, adopted by NIST, designed to protect data for decades.

The catch: implementing PQC correctly is hard. The key sizes are larger than RSA. The algorithms behave differently. Integration with existing systems needs thought. And you need proper randomness — real entropy — to generate quantum-safe keys. A bad random number generator breaks any cryptographic system, classical or quantum.

This is where quantumAPI comes in. It’s a European platform that provides post-quantum cryptography as a service — no need to implement ML-KEM yourself, no need to worry about entropy. The platform uses real Quantum Random Number Generation (QRNG) hardware to generate keys, and exposes everything through a clean REST API.

Three products, each solving a different part of the problem:

  • QuantumVault — quantum-safe key management and secrets storage. Think Azure Key Vault, but with ML-KEM key wrapping and QRNG key generation.
  • QuantumAPI EaaS — encryption as a service. Send data, get back quantum-safe ciphertext. Hybrid ML-KEM + AES-256-GCM under the hood.
  • QuantumID — identity and access management with quantum-safe token signing. OIDC/OAuth2 with ML-DSA signatures instead of RS256.

This series covers all three, with real code, applied to real systems. We’ll use the same .NET users API and Azure DevOps pipeline from the ATLAS+GOTCHA series as the base — and secure it properly.

Execute

Let’s start simple: get an API key and make your first call.

Step 1: Register

Go to quantumapi.eu and create an account. The free tier gives you access to all three products with generous limits — enough to follow along with this series.

After registration, go to API Keys in your dashboard and create a new key. It’ll look like this:

qid_xxxxxxxxxxxxxxxxxxxxxxxxxxxx

Keep it safe. Don’t commit it to your repository. We’ll use environment variables in all examples.

Step 2: Install the qapi CLI

QuantumAPI ships a CLI called qapi. It’s the easiest way to interact with any QuantumAPI service from your terminal or CI/CD pipeline.

brew install quantumapi-eu/tap/qapi

Then log in (opens a browser tab):

qapi login

For non-interactive environments (CI/CD, scripts), use the QAPI_API_KEY environment variable instead:

export QAPI_API_KEY=qid_your_api_key_here

Check everything is working:

qapi health

Step 3: Your first QRNG call

QRNG — quantum random number generation — is available via the REST API. Real randomness from Quantum Blockchains hardware in the EU, not a software generator:

curl https://api.quantumapi.eu/api/v1/qrng?bytes=32 \
  -H "X-Api-Key: $QAPI_API_KEY"

Response:

{
  "bytes": 32,
  "data": "7f3a9c2e1b4d8f6a0e5c7b3d9f1a4e2c8b6d0a5e3c7b1f9d4a8e2b6c0f4a7d3",
  "source": "QuantumBlockchains",
  "generatedAt": "2026-04-02T10:00:00Z"
}

Step 4: Your first encryption

For encryption and decryption the qapi CLI handles everything:

qapi encrypt "hello, quantum world"

The output is a single base64 string — the encrypted payload you store or pass around:

eyJjIjoidW14OUpmQ...

To decrypt, pass it back:

qapi decrypt "eyJjIjoidW14OUpmQ..."

Output:

hello, quantum world

That’s it. Two commands. Quantum-safe encryption without implementing a single cryptographic algorithm yourself.

Step 5: .NET SDK

For the rest of this series we’ll use the QuantumAPI.Client NuGet package:

dotnet add package QuantumAPI.Client

Quick smoke test:

using QuantumAPI.Client;

var client = new QuantumApiClient(new QuantumApiOptions
{
    ApiKey = Environment.GetEnvironmentVariable("QUANTUMAPI_KEY")!
});

var result = await client.Encryption.EncryptAsync(new EncryptRequest
{
    Plaintext = "sensitive data",
    Encoding = "utf8"
});

Console.WriteLine($"Algorithm: {result.Algorithm}");
Console.WriteLine($"Key ID: {result.KeyId}");

Set your key in the environment before running:

export QUANTUMAPI_KEY=qid_your_api_key_here
dotnet run

Template

Use this checklist to assess your current exposure. Honest answers only — this is a starting point.

=== POST-QUANTUM READINESS CHECKLIST ===

DATA AT REST
[ ] Are database fields with PII or financial data encrypted at the application level?
[ ] What algorithm? (RSA, AES-256, or something else?)
[ ] If RSA-wrapped keys are used — these are at risk.
[ ] If AES-256-GCM is used directly — AES is quantum-resistant (Grover halves security,
    but AES-256 becomes AES-128 equivalent — still safe).

DATA IN TRANSIT
[ ] All HTTPS? (TLS 1.3 preferred — it includes ECDHE which is PQC-upgradeable)
[ ] Any mTLS between services? What certificate algorithm?
[ ] JWT tokens: what signing algorithm? RS256 (RSA) = at risk. HS256 (HMAC) = safer.

SECRETS & KEYS
[ ] Where are private keys stored?
[ ] Are they wrapped with RSA or ECDH? — at risk.
[ ] Azure Key Vault: key operations use RSA by default — check your key types.

AUTHENTICATION
[ ] Passwords: hashed with Argon2id or bcrypt? — quantum-resistant.
[ ] API keys: HMAC-based? — quantum-resistant.
[ ] JWT: RS256 signing? — at risk. Switch to HS256 or quantumID ML-DSA.
[ ] OAuth2 / OIDC: check provider's signing algorithm.

TIMELINE & DATA SENSITIVITY
[ ] How long does your sensitive data need to stay private?
  - < 5 years: lower priority (but don't wait)
  - 5-15 years: medium priority (plan migration now)
  - > 15 years or regulated: high priority (act now)

COMPLIANCE
[ ] Are you in a regulated sector? (finance, health, energy, government)
[ ] Has your security audit asked about cryptographic agility?
[ ] Are you subject to NIS2, eIDAS 2.0, or equivalent?

Challenge

Before article 2, do one thing: find one place in your codebase where a secret is stored outside a vault. A connection string in appsettings.json. A JWT secret in an environment variable that nobody rotates. A private key committed to a repository years ago.

You’ll almost certainly find one. That’s what article 2 is about: QuantumVault, and how to fix it for good.

If this series helps you, consider buying me a coffee.

Comments

Loading comments...