BIBLIOTECA ASTRACode Cyber

CAPÍTULO 66 · PARTE VI

Criptografía asimétrica y problemas difíciles

Explica pares de claves, supuestos computacionales, PKE y KEM, composición híbrida, validación y por qué una clave pública no es una identidad autenticada.

Nivel N2 · Estado published

La criptografía asimétrica separa capacidades que en la criptografía simétrica pertenecían a la misma clave. Una parte de un key pair puede distribuirse; la otra debe permanecer bajo control. Esa separación permite cifrar hacia un destinatario, establecer secretos y verificar firmas sin compartir de antemano el mismo secreto con cada participante.

No elimina el problema de confianza: lo desplaza. Antes de usar una public key hay que saber a quién pertenece, para qué sirve, qué parámetros usa y si continúa vigente. La seguridad tampoco nace de que una operación sea «matemáticamente complicada». Depende de un supuesto computacional preciso, un scheme analizado, parámetros suficientes, inputs válidos y una implementación que no filtre la trapdoor.

Dos claves, capacidades distintas

Un algoritmo de generación produce (pk, sk). pk es public key; sk, private key. «Pública» significa que su divulgación forma parte del diseño, no que cualquier copia sea auténtica ni que pueda usarse para cualquier propósito. «Privada» significa que habilita una capacidad sensible; no prueba que una persona concreta la haya ejercido.

En public-key encryption, un sender usa pk_R para formar ciphertext destinado al holder de sk_R. En un KEM, usa pk_R para encapsular un shared secret y produce un encapsulated value enc; el recipient usa sk_R para decapsular. En una firma, que se estudiará en el capítulo 67, la dirección de capacidad es otra: sk firma y pk verifica.

Mezclar esas operaciones bajo la frase «cifrar con la privada» destruye contratos importantes. Una firma no es encryption invertido; padding, security game, encoding y manejo de errores son distintos. Las bibliotecas deben exponer schemes, no una primitiva algebraica genérica que invite a permutar exponentes.

Cualquier actor que obtiene pk_R puede normalmente cifrar o encapsular hacia R. Por tanto, decryption exitosa no autentica al sender en un base mode. Puede probar que el ciphertext es válido bajo el scheme y contexto; no quién lo creó. Sender authentication requiere otra propiedad: firma, PSK, authenticated KEM mode o protocolo que ligue transcript e identidades.

Difícil no significa imposible

La seguridad public-key suele ser computacional. Un adversario con recursos y tiempo acotados no debería ganar un juego con probabilidad relevante. No se afirma que recuperar el secreto sea lógicamente imposible ni que ninguna mejora algorítmica futura exista.

Un problema formula una tarea: factorizar un entero compuesto, hallar un discrete logarithm o resolver una instancia de Learning with Errors. Un supuesto declara que cierta familia de instancias y distribución es difícil para un adversario definido. Un scheme usa esa estructura para alcanzar una propiedad. Una reducción relaciona un ataque al scheme con resolver el problema bajo un modelo.

Cada palabra importa. Una reducción asintótica puede perder factores que afectan seguridad concreta. Un proof puede usar random-oracle model. El problema puede ser difícil en promedio para una distribución y fácil en subgrupos o parámetros degenerados. El adversario puede obtener decryption queries, timing, faults o leakage que el modelo básico no contempla.

La cadena defendible es:

problema → supuesto → construcción → parámetros → encoding/validación → composición → implementación

Saltar del primer nodo a «seguro» oculta casi toda la ingeniería.

RSA: función, trapdoor y encoding

RSA trabaja sobre aritmética modular con un modulus n = p·q. La public key contiene n y un exponent público; la private key permite computar la operación inversa eficientemente. Conocer la factorización permite derivar información privada suficiente para invertir la función.

Eso no autoriza la frase «romper RSA es exactamente equivalente a factorizar». Factorizar n es una vía suficiente; la equivalencia general entre toda inversión RSA y factorization no está demostrada para cualquier formulación. El supuesto concreto suele expresarse como dificultad de invertir la RSA function bajo parámetros y distribución definidos.

Textbook RSA es determinista y algebraicamente maleable. No es un encryption scheme seguro. RFC 8017 define RSAES-OAEP con encoding aleatorizado y parámetros de hash/MGF; también conserva RSAES-PKCS1-v1_5 por compatibilidad, con un historial de oracles que obliga a extrema cautela. RFC 8017

La decryption path no debe revelar si falló un byte de padding, el label, la longitud o la operación modular. Respuesta, timing y efectos deben impedir que queries adaptativas conviertan el receptor en oracle. «Error genérico» en el body no basta si la ruta interna sigue siendo distinguible.

RFC 8017 tampoco recomienda reutilizar un RSA key pair en múltiples schemes para aplicaciones nuevas. Una debilidad u oracle en el scheme legacy puede comprometer ciphertext del scheme moderno que comparte la misma trapdoor. Separar keys por propósito limita cross-protocol attack y permite retirar un uso sin romper los demás.

Discrete logarithm, DH y elliptic curves

En un grupo cíclico, el discrete logarithm problem pregunta por x dado un generator g y g^x. Computational Diffie–Hellman (CDH) pregunta por g^(ab) dados g^a y g^b. Decisional Diffie–Hellman (DDH) pide distinguir un tuple válido de uno aleatorio. Están relacionados, pero no son la misma pregunta ni tienen igual dificultad en todos los grupos.

Elliptic-curve cryptography usa grupos construidos con puntos de una curva sobre un finite field. La operación se escribe aditivamente: de P y xP se supone difícil recuperar x. ECC puede alcanzar niveles comparables con public keys menores que finite-field systems, pero «curva elíptica» no es un sello de seguridad. Curva, subgroup, encoding, scalar handling y validation siguen siendo parte del scheme.

SP 800-56A Rev. 3 especifica key establishment basado en discrete logarithm sobre finite fields y elliptic curves. NIST decidió actualizarla en enero de 2026; la edición de 2018 sigue siendo la final vigente mientras esa actualización no se publique. NIST SP 800-56A Rev. 3

RFC 7748 define X25519 y X448. El output de X25519 no se usa directamente como application key: se introduce en una KDF junto con transcript/context. El RFC permite comprobar el all-zero result y abortar, porque ciertas small-order inputs lo producen. RFC 7748, §6

La validación exacta depende del perfil. Copiar una checklist de otra curva puede rechazar valores permitidos o aceptar estados degenerados. Se usa la primitive mantenida con su contrato, no una validación inventada alrededor de coordenadas.

Lattices y Module-LWE

Post-quantum cryptography busca schemes basados en problemas para los que no se conoce un ataque eficiente ni clásico ni cuántico dentro de los modelos considerados. No significa «demostrado invulnerable a cualquier computadora cuántica».

FIPS 203 estandariza ML-KEM y vincula su seguridad a Module Learning with Errors. De forma conceptual, el adversario observa relaciones lineales modulares perturbadas por error pequeño; recuperar el secreto o distinguir la distribución debe ser difícil. La estructura module equilibra tamaño y eficiencia, pero el contrato real es el algoritmo completo, no la palabra lattice. NIST FIPS 203

FIPS 203 define ML-KEM-512, ML-KEM-768 y ML-KEM-1024. El número identifica un parameter set, no bits simples de key strength intercambiables con AES. La selección considera security category, tamaños, rendimiento, protocolo y policy. La publicación tiene una planning note de 2025 sobre potential updates; continúa final, pero una implementación debe seguir errata y perfil aplicables.

ML-KEM es un KEM, no bulk encryption ni firma. FIPS 204 y 205 cubren schemes de firma post-quantum diferentes. Adoptar ML-KEM no migra certificates, signatures, HSMs, protocols, wire formats ni inventarios por sí solo.

PKE y KEM no son la misma interfaz

Un public-key encryption scheme suele ofrecer:

Un key-encapsulation mechanism ofrece:

ek/dk enfatizan encapsulation/decapsulation keys. Si enc es válido, ambas partes obtienen el mismo shared secret. El scheme define qué ocurre con un valor inválido: error, implicit rejection u otra salida con contrato preciso. La aplicación no debe reemplazarlo con excepciones distinguibles.

SP 800-227, final desde septiembre de 2025, define propiedades y recomendaciones para KEMs. Subraya que el secret establecido alimenta symmetric cryptography; el KEM no transporta automáticamente mensajes arbitrarios. NIST SP 800-227

La correctness probability también importa. Algunos schemes admiten probabilidad de decapsulation failure extremadamente pequeña. «Negligible» es una claim matemática bajo parámetros, no permiso para tratar cualquier fallo como corrupción aleatoria. Telemetría, tests y response deben distinguir operación interna sin crear oracle externo.

Hybrid encryption: KEM, KDF y AEAD

La asimetría es costosa y restringe tamaños. El patrón moderno establece key material asimétricamente y cifra bulk data con AEAD simétrica:

  1. autenticar o resolver la recipient public key;
  2. Encaps(pk_R) produce enc y ss;
  3. una KDF deriva AEAD key, base nonce y contexto desde ss y transcript;
  4. AEAD cifra el plaintext y autentica AAD;
  5. el recipient ejecuta Decaps(sk_R, enc), repite KDF y abre AEAD;
  6. cualquier fallo termina sin plaintext ni efecto.

ss no viaja. enc y AEAD ciphertext pueden ser públicos. Separar KEM y data encryption permite usar constructions diseñadas para cada tarea y versionarlas como una ciphersuite.

RFC 9180 define HPKE como composición de KEM, KDF y AEAD. Su base mode cifra hacia la recipient public key, pero no autentica al sender. Auth, PSK y AuthPSK añaden propiedades distintas y no todos los KEM soportan authenticated interface. RFC 9180

info y AAD ligan contexto, pero no reparan una key sustituida. La ciphersuite y wire format deben ser inequívocos. RFC 9180 no define un wire format completo: la aplicación especifica encoding de enc, ciphertext, ordering e info no implícita.

La public key todavía necesita autenticidad

Si Mara descarga pk_bank por un canal que Leo controla, Leo reemplaza la key por pk_leo. Mara ejecuta una KEM impecable, deriva una AEAD key y sube su archivo. Todo valida: para la clave equivocada. Leo decapsula con sk_leo.

El cifrado no falló. Faltó un binding confiable entre public key y banco, incluido propósito, tenant, algorithm, validity period y revocation state. Certificates y PKI son una solución posible; pinning, trust-on-first-use, transparency logs o entrega presencial tienen otros contratos. El capítulo 69 los comparará.

Una fingerprint leída por el mismo canal comprometido tampoco arregla el problema. Debe existir evidencia independiente o una cadena de confianza ya establecida. «Está en DNS» sólo autentica si se especifica cómo se protege esa resolución y qué identity claim se acepta.

Public key authenticity y sender authentication son ejes diferentes. Una recipient key auténtica permite confidencialidad hacia el destinatario correcto; cualquier sender puede usarla en base mode. Una sender signature puede autenticar origen sin ocultar plaintext. Un protocolo puede necesitar ambas.

Validar inputs antes de atribuir propiedades

Las public keys y encapsulated values son input no confiable. El scheme exige longitudes, encoding, domain membership y checks específicos. Una entrada inválida puede forzar shared secrets degenerados, activar exceptional paths o crear side channels.

La validación ocurre dentro de la primitive/biblioteca cuando corresponde. Duplicarla fuera puede introducir parsing diferencial: la app acepta una representación que la biblioteca interpreta de otra forma. El protocolo fija una encoding canónica y rechaza trailing bytes, algorithm confusion y tamaños descontrolados.

Decapsulation/decryption se diseña como una frontera de confianza:

Un attacker no debe elegir libremente entre RSA legacy, EC y ML-KEM mediante un algorithm field sin autenticar. La negotiation queda ligada al transcript y a una allowlist; downgrade y unsupported version fallan cerrados.

Custodia de la private key

El diseño asimétrico concentra poder en sk. Copiarla a cada verifier o worker puede borrar la ventaja arquitectónica. El inventario debe conocer quién puede decapsular o firmar, bajo qué purpose y con qué audit trail.

Un HSM puede hacer non-exportable el material, pero no impide abuso de una caller identity autorizada. Se separan permissions por operation, key-id, tenant y rate; se requiere attestation o approval cuando el riesgo lo justifica. Backup, restore y disaster recovery preservan confidencialidad y availability sin multiplicar copias invisibles.

Keys de largo plazo y ephemeral keys tienen consecuencias distintas. Comprometer una static decryption key puede exponer ciphertext histórico almacenado. Forward secrecy requiere ephemeral contributions y erasure dentro de un protocolo; no aparece por usar ECC. El capítulo 68 desarrolla este punto.

La rotación necesita publicar la nueva pk antes de cifrar hacia ella, conservar sk_old sólo durante una ventana definida y distinguir mensajes creados antes/después del corte. Borrar sk_old demasiado pronto pierde datos; conservarla indefinidamente prolonga exposure.

Amenaza cuántica y transición

Shor convierte factoring y discrete logarithm en objetivos vulnerables para una computadora cuántica criptográficamente relevante. Eso afecta RSA, finite-field DH y ECC. No implica que tal máquina exista hoy con capacidad operativa suficiente, pero datos de larga confidencialidad pueden capturarse ahora y descifrarse después.

ML-KEM está diseñado frente a adversarios clásicos y cuánticos conocidos bajo sus supuestos. La transición sigue necesitando inventario, crypto agility, hybrid schemes cuando el perfil los define, pruebas, tamaño de mensajes, performance, hardware y rollback seguro.

NIST IR 8547 describe una propuesta de transición, pero en la consulta actual sigue como Initial Public Draft. Sus timelines no deben citarse como obligación final universal. NIST IR 8547 IPD

Combinar classical y post-quantum secrets puede reducir dependencia de una sola familia si el combiner y protocolo están analizados. Concatenar outputs improvisadamente no acredita hybrid security. SP 800-227 incluye recomendaciones específicas; el perfil aplicable decide construcción e invariants.

Caso trabajado: backup cifrado para la key equivocada

Una aplicación obtiene una public key desde keys.example.test, la cachea treinta días y cifra backups con un home-grown RSA wrapper. No valida TLS porque «la key es pública». Un attacker sustituye el response. Los backups quedan cifrados correctamente para él.

La remediación comienza antes de la primitive:

  1. autenticar el endpoint y ligar hostname, account y purpose;
  2. fijar un key manifest firmado o una trust path verificable;
  3. usar key-id y algorithm suite autenticados, con validity window;
  4. reemplazar raw RSA por un perfil hybrid mantenido;
  5. encapsular, derivar con context y cifrar el backup mediante AEAD;
  6. incluir account, backup-id, version y recipient-key-id como contexto;
  7. probar substitution, stale key, revoked key y downgrade;
  8. conservar old private keys sólo durante recovery policy.

Una prueba positiva confirma que el owner puede restaurar. Una prueba negativa sustituye pk y exige fallo antes de enviar datos. Otra mueve el ciphertext a otra account y espera que AAD/authorization rechacen. La observación relevante no es «decrypt devolvió bytes», sino que sólo el principal y contexto previstos pueden producir un restore autorizado.

Método de revisión

Para cualquier uso de criptografía asimétrica, responde:

  1. Propiedad: ¿confidencialidad, key establishment, firma o combinación?
  2. Scheme: ¿qué construcción exacta y security game?
  3. Supuesto: ¿RSA inversion, CDH/DDH, Module-LWE u otro?
  4. Parámetros: ¿quién los fija y qué strength representan?
  5. Binding: ¿cómo se autentica owner, tenant, purpose y vigencia de pk?
  6. Inputs: ¿encoding, longitud, domain membership y key checks?
  7. Composición: ¿KEM→KDF→AEAD con domains y transcript correctos?
  8. Autenticación: ¿quién puede crear ciphertext y qué prueba sobre sender?
  9. Errores: ¿decapsulation/decryption crea oracle o efecto parcial?
  10. Private key: ¿custodia, permisos, backup, rotation y destruction?
  11. Separación: ¿una key por scheme/purpose o reuse justificado?
  12. Transición: ¿downgrade, coexistencia classical/PQ y rollback?
  13. Evidencia: ¿vectors, negatives, invalid keys, substitution y cross-context?

Los tests usan official vectors y casos inválidos: tamaños ±1, encodings no canónicos, all-zero donde aplique, encapsulated value alterado, wrong private key, suite desconocida, key expirada y public-key substitution. Se comprueba que un FAIL no libera plaintext, secret ni timing trivialmente clasificable y que logs no contienen sk, shared secret o derived keys.

La prueba de composición debe conservar el mismo transcript en ambos extremos y fallar si cambia suite-id, recipient key, info, AAD u orden de campos. También se ejecuta una matriz de rotación: ciphertext nuevo con key vieja, ciphertext viejo con key nueva, key retirada y dos recipients simultáneos. En cada celda se observa qué material se seleccionó antes de decapsular y si el rechazo ocurrió sin fallback. Para mecanismos con probabilidad de fallo no nula, la prueba separa el comportamiento permitido por la especificación de corrupción, fault injection y error de integración; agruparlos todos como «fallo aleatorio» ocultaría evidencia operacional decisiva.

Transferencia al capítulo 67

El key pair crea capacidades asimétricas, pero todavía no se ha definido una firma. El capítulo 67 separará signing de encryption, explicará unforgeability, hashing y encoding, y mostrará qué demuestra —y qué no— una verificación válida.

Síntesis

La criptografía asimétrica distribuye una public capability y protege una private capability. Publicar una key no la liga automáticamente a una identidad; poseer la private key no prueba intención humana.

RSA, discrete-log/CDH y Module-LWE son familias de supuestos diferentes. Un hard problem no salta directamente a seguridad: construction, parameters, validation, composition e implementation son gates separados.

KEM establece shared key material; KDF lo contextualiza; AEAD cifra datos. HPKE ejemplifica esa composición y mantiene base sender-unauthenticated. ML-KEM aporta un KEM post-quantum estandarizado, no una migración completa.

La pregunta profesional no es «¿usa public-key crypto?». Es qué capacidad se creó, bajo qué supuesto, para qué key auténtica y qué evidencia demuestra que ningún error de parsing, oracle, lifecycle o transición amplió esa claim.

Fuentes primarias y documentación técnica