Quantum-Safe Cloud -- Parte 1

Por qué tu cifrado tiene fecha de caducidad

#security #post-quantum #cryptography #quantumapi

El Problema

Tu base de datos está cifrada. Tu API usa HTTPS. Tus secretos están en Key Vault. Lo estás haciendo bien.

Pero hay algo que la mayoría de desarrolladores no saben: el cifrado que protege esos datos tiene fecha de caducidad. No por un bug de software. Por la física.

En agosto de 2024, NIST publicó los tres primeros estándares criptográficos post-cuánticos. Son los reemplazos de RSA y la criptografía de curvas elípticas — los algoritmos que protegen casi toda la comunicación segura en internet hoy. NIST no publica estándares de emergencia sin motivo. El motivo son los ordenadores cuánticos.

Un ordenador cuántico suficientemente potente ejecutando el algoritmo de Shor puede romper RSA-2048 y ECC en horas. No años. Horas. Las mismas claves que protegen tu tráfico HTTPS, tus tokens JWT, el cifrado de tu base de datos.

“Pero los ordenadores cuánticos todavía no son lo bastante potentes.” Es verdad. Los más avanzados hoy no pueden romper la criptografía de producción. Las estimaciones varían — algunos dicen 5 años, otros 15. Nadie sabe exactamente. Pero aquí está la parte que cambia el cálculo:

Harvest now, decrypt later (recopilar ahora, descifrar después).

Los atacantes no necesitan un ordenador cuántico hoy. Solo necesitan grabar tu tráfico cifrado hoy y descifrarlo más tarde cuando los ordenadores estén listos. Agencias de inteligencia, grupos de crimen organizado y actores estatales ya lo están haciendo. Si tus datos tienen valor más allá de los próximos 5-10 años — registros financieros, datos de salud, comunicaciones gubernamentales, propiedad intelectual — ya están en riesgo.

Y para industrias reguladas, la fecha límite no es “cuando lleguen los ordenadores cuánticos.” La fecha de cumplimiento normativo es ahora. La guía de migración de NIST y las regulaciones de la UE bajo eIDAS 2.0 ya exigen preparación post-cuántica. Los auditores de NIS2 están haciendo preguntas sobre agilidad criptográfica.

La fecha de caducidad de tu cifrado es real. La pregunta es qué haces al respecto antes de que expire.

La Solución

La criptografía post-cuántica (PQC) reemplaza RSA y ECC con algoritmos que son difíciles de romper incluso para ordenadores cuánticos. Se basan en problemas matemáticos diferentes — retículos, funciones hash — que el algoritmo de Shor no puede explotar.

NIST estandarizó tres algoritmos en agosto de 2024:

  • ML-KEM (FIPS 203, basado en CRYSTALS-Kyber) — para encapsulación de claves. Reemplaza el intercambio de claves RSA y ECDH.
  • ML-DSA (FIPS 204, basado en CRYSTALS-Dilithium) — para firmas digitales. Reemplaza las firmas RSA y ECDSA.
  • SLH-DSA (FIPS 205, basado en SPHINCS+) — un esquema de firma alternativo basado en funciones hash.

No son experimentales. Son estándares publicados, adoptados por NIST, diseñados para proteger datos durante décadas.

El problema: implementar PQC correctamente es difícil. Los tamaños de clave son más grandes que RSA. Los algoritmos se comportan de forma diferente. La integración con sistemas existentes requiere planificación. Y necesitas aleatoriedad real — entropía real — para generar claves quantum-safe. Un mal generador de números aleatorios rompe cualquier sistema criptográfico, clásico o cuántico.

Aquí es donde entra quantumAPI. Es una plataforma europea que ofrece criptografía post-cuántica como servicio — no necesitas implementar ML-KEM tú mismo, no necesitas preocuparte por la entropía. La plataforma usa hardware real de Quantum Random Number Generation (QRNG) para generar claves, y expone todo a través de una API REST limpia.

Tres productos, cada uno resuelve una parte diferente del problema:

  • QuantumVault — gestión de claves quantum-safe y almacenamiento de secretos. Piensa en Azure Key Vault, pero con key wrapping ML-KEM y generación de claves QRNG.
  • QuantumAPI EaaS — cifrado como servicio. Envías datos, recibes texto cifrado quantum-safe. Hybrid ML-KEM + AES-256-GCM por debajo.
  • QuantumID — gestión de identidad y acceso con firma de tokens quantum-safe. OIDC/OAuth2 con firmas ML-DSA en lugar de RS256.

Esta serie cubre los tres, con código real, aplicado a sistemas reales. Usaremos la misma API de usuarios en .NET y el pipeline de Azure DevOps de la serie ATLAS+GOTCHA como base — y la aseguraremos correctamente.

Ejecución

Empecemos simple: consigue una API key y haz tu primera llamada.

Paso 1: Registro

Ve a quantumapi.eu y crea una cuenta. El tier gratuito te da acceso a los tres productos con límites generosos — suficiente para seguir esta serie.

Después de registrarte, ve a API Keys en tu dashboard y crea una nueva clave. Tendrá este aspecto:

qid_xxxxxxxxxxxxxxxxxxxxxxxxxxxx

Guárdala bien. No la subas a tu repositorio. Usaremos variables de entorno en todos los ejemplos.

Paso 2: Instalar el CLI qapi

QuantumAPI incluye un CLI llamado qapi. Es la forma más fácil de interactuar con cualquier servicio de QuantumAPI desde tu terminal o pipeline de CI/CD.

brew install quantumapi-eu/tap/qapi

Luego inicia sesión (abre una pestaña del navegador):

qapi login

Para entornos no interactivos (CI/CD, scripts), usa la variable de entorno QAPI_API_KEY:

export QAPI_API_KEY=qid_your_api_key_here

Comprueba que todo funciona:

qapi health

Paso 3: Tu primera llamada QRNG

QRNG — quantum random number generation — está disponible a través de la API REST. Aleatoriedad real desde hardware de Quantum Blockchains en la UE, no un generador por software:

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

Respuesta:

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

Paso 4: Tu primer cifrado

Para cifrar y descifrar, el CLI qapi se encarga de todo:

qapi encrypt "hello, quantum world"

La salida es una cadena base64 — el payload cifrado que almacenas o pasas a otros servicios:

eyJjIjoidW14OUpmQ...

Para descifrar, pásalo de vuelta:

qapi decrypt "eyJjIjoidW14OUpmQ..."

Salida:

hello, quantum world

Eso es todo. Dos comandos. Cifrado quantum-safe sin implementar un solo algoritmo criptográfico tú mismo.

Paso 5: SDK de .NET

Para el resto de esta serie usaremos el paquete NuGet QuantumAPI.Client:

dotnet add package QuantumAPI.Client

Test rápido:

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}");

Configura tu clave en el entorno antes de ejecutar:

export QUANTUMAPI_KEY=qid_your_api_key_here
dotnet run

Plantilla

Usa este checklist para evaluar tu exposición actual. Respuestas honestas — esto es un punto de partida.

=== 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?

Reto

Antes del artículo 2, haz una cosa: encuentra un lugar en tu código donde un secreto esté almacenado fuera de un vault. Un connection string en appsettings.json. Un secreto JWT en una variable de entorno que nadie rota. Una clave privada que se subió a un repositorio hace años.

Seguro que encuentras uno. De eso va el artículo 2: QuantumVault, y cómo solucionarlo de verdad.

Si esta serie te resulta útil, considera invitarme a un café.

Comments

Loading comments...