Cómo implementar crypto-agility sin detener tu operación: arquitecturas híbridas paso a paso

El problema de la criptografía rígida

La mayoría de los sistemas de software tienen la criptografía cosida al código: el algoritmo, el tamaño de clave y el modo de operación están escritos directamente en las llamadas a la biblioteca, en los archivos de configuración o en las constantes del código fuente. Cambiar ese algoritmo implica encontrar cada referencia, entender las dependencias, actualizar las pruebas y desplegar una nueva versión. En sistemas distribuidos, ese proceso puede llevar meses.

La crypto-agility es el diseño opuesto: una arquitectura donde el algoritmo criptográfico es un parámetro configurable, no una decisión fija en el código. El sistema puede cambiar de RSA a ML-KEM, o de AES-128 a AES-256, sin modificar la lógica de negocio ni rediseñar la infraestructura.

El esquema híbrido: seguridad en capas

Durante el período de transición, ninguna organización debería abandonar sus algoritmos clásicos de forma abrupta. La estrategia recomendada por el NIST, la NSA y el NCSC es el esquema híbrido: ejecutar un algoritmo clásico y uno post-cuántico en paralelo, y derivar la clave final combinando ambas salidas.

La lógica es simple: si el algoritmo PQC resultara comprometido, el clásico sigue protegiendo la sesión. Si el algoritmo clásico fuera roto por una computadora cuántica, el PQC mantiene la seguridad. El atacante necesita romper ambos simultáneamente para comprometer la comunicación. En TLS 1.3, el esquema híbrido más utilizado combina X25519 con ML-KEM-768, referenciado en los borradores del IETF como X25519MLKEM768.

ssl_protocols TLSv1.3;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;

openssl s_client -connect tu-servidor.com:443 \
    -groups X25519MLKEM768 2>&1 | grep "Server Temp Key"
    

Abstraer la criptografía del código de negocio

El primer paso para lograr crypto-agility en una aplicación es identificar todos los puntos donde se toman decisiones criptográficas y envolverlos en una capa de abstracción. En lugar de llamar directamente a funciones de cifrado específicas, el código de negocio interactúa con una interfaz genérica que delega en una implementación intercambiable.

interface CryptoProvider {
    public function encrypt(string $data, string $key): string;
    public function decrypt(string $data, string $key): string;
}

class UserService {
    public function __construct(
        private CryptoProvider $crypto
    ) {}

    public function encryptData(string $data): string {
        return $this->crypto->encrypt($data, $this->key);
    }
}

app()->bind(CryptoProvider::class, MlKemProvider::class);
    

Integrar liboqs y oqs-provider en el pipeline

La biblioteca liboqs del proyecto Open Quantum Safe es la implementación de referencia en C para todos los algoritmos NIST PQC. Se puede integrar en aplicaciones PHP, Python, Go, Java y Rust a través de los bindings correspondientes. Para entornos que usan OpenSSL, el oqs-provider expone los algoritmos de liboqs como un proveedor estándar de OpenSSL 3.x, sin necesidad de modificar el código que ya usa la API de OpenSSL.

git clone https://github.com/open-quantum-safe/liboqs.git
cd liboqs && mkdir build && cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr/local ..
make -j$(nproc) && sudo make install

git clone https://github.com/open-quantum-safe/oqs-provider.git
cd oqs-provider && mkdir build && cd build
cmake -DOPENSSL_ROOT_DIR=/usr/local/ssl ..
make -j$(nproc) && sudo make install

openssl list -kem-algorithms -provider oqsprovider | grep ML-KEM
openssl list -signature-algorithms -provider oqsprovider | grep ML-DSA
    

Automatizar el inventario en el pipeline CI/CD

Una práctica central de crypto-agility es mantener el inventario criptográfico actualizado de forma automática. El formato CBOM (Cryptography Bill of Materials) de CycloneDX 1.6 permite documentar cada algoritmo, clave y certificado usado en el sistema, de manera legible por máquinas y auditable. Integrarlo en el pipeline de CI/CD garantiza que cualquier nuevo algoritmo vulnerable introducido en el código sea detectado antes de llegar a producción.

name: Auditoría criptográfica

on: [push, pull_request]

jobs:
  crypto-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Escanear algoritmos vulnerables
        run: |
          grep -rn "RSA\|DH\|ECDSA\|SHA1\|MD5" src/ \
            --include="*.php" --include="*.py" \
            > crypto-findings.txt || true

      - name: Generar CBOM
        run: |
          cyclonedx-cli analyze --path . \
            --output-format json \
            --output-file sbom-crypto.json

      - name: Subir reporte como artefacto
        uses: actions/upload-artifact@v4
        with:
          name: crypto-audit-report
          path: |
            crypto-findings.txt
            sbom-crypto.json
    

Estrategia de despliegue gradual

• Fase 1 (tráfico interno): habilitar híbrido X25519 + ML-KEM-768 entre microservicios internos. Medir overhead de latencia y tamaño de handshake.
• Fase 2 (5% externo): activar en un subconjunto de usuarios o región secundaria. Monitorear compatibilidad de clientes.
• Fase 3 (rollout completo): expandir al 100% del tráfico. Mantener fallback a clásico para clientes que no soporten los nuevos grupos.
• Fase 4 (deprecación clásica): cuando la adopción del cliente sea suficiente, eliminar los grupos clásicos solos y exigir híbrido como mínimo.

Conclusión

La crypto-agility no es una técnica exclusiva de la era post-cuántica: es una práctica de ingeniería sólida que reduce el costo de cualquier migración criptográfica futura. Implementarla ahora, junto con el despliegue híbrido de ML-KEM y ML-DSA, permite a las organizaciones avanzar en la transición post-cuántica sin detener la operación, sin rediseñar sistemas completos y con la posibilidad de revertir si fuera necesario. La combinación de abstracción en el código, inventario automatizado en CI/CD y despliegue gradual es el camino más pragmático hacia una infraestructura quantum-ready.