4 min

Ron Rivest y la criptografía práctica: por qué ganó RSA

Cómo Ron Rivest ayudó a moldear la criptografía práctica: RSA, firmas y las decisiones de ingeniería de seguridad que hicieron comunes el comercio seguro y HTTPS.

Ron Rivest y la criptografía práctica: por qué ganó RSA

Por qué Rivest importa para la seguridad cotidiana

Ron Rivest es uno de esos nombres que rara vez se oyen fuera de los círculos de seguridad, pero su trabajo define en silencio cómo se siente la “seguridad normal” en línea. Si alguna vez iniciaste sesión en un banco, compraste algo con tarjeta o confiaste en que un sitio web era el que pretendías visitar, te has beneficiado de un estilo de pensamiento que Rivest ayudó a popularizar: criptografía que funciona en el mundo real, no solo en papel.

El problema real: secreto a escala de internet

La comunicación segura es difícil cuando millones de desconocidos necesitan interactuar. No se trata solo de mantener mensajes privados: también se trata de probar identidad, prevenir manipulaciones y asegurarse de que los pagos no se falsifiquen ni redirijan silenciosamente.

En un grupo pequeño puedes compartir un código secreto de antemano. En internet, ese enfoque se desmorona: no puedes precompartir un secreto con cada sitio, almacén y servicio que podrías usar.

“Seguridad por defecto” = matemáticas + ingeniería + estándares

La influencia de Rivest está ligada a una idea mayor: la seguridad se generaliza solo cuando pasa a ser la opción por defecto. Eso requiere tres ingredientes que trabajen juntos:

  • Matemáticas: primitivas criptográficas robustas (como RSA) que permiten interacciones seguras entre desconocidos.
  • Ingeniería: generación de claves, almacenamiento seguro, copias de seguridad, rotación, controles de acceso: todo lo que evita que las buenas matemáticas se vengan abajo por errores.
  • Estándares: reglas acordadas (protocolos, formatos de certificados, comportamiento del navegador) para que la misma seguridad funcione en todas partes, automáticamente.

Qué esperar en este artículo

Este es un recorrido de alto nivel y no matemático sobre cómo RSA encajó en una pila de seguridad práctica —cifrado, firmas, certificados y HTTPS— y por qué esa pila hizo que el comercio y la comunicación seguros fueran rutinarios en lugar de excepcionales.

El problema central: compartir secretos a escala de internet

Antes de RSA, la mayoría de la comunicación segura funcionaba como un candado de diario compartido: ambas personas necesitaban la misma clave secreta para cerrar y abrir mensajes. Esto es criptografía simétrica: rápida y eficaz, pero asume que ya tienes una forma segura de compartir ese secreto.

La criptografía de clave pública invierte la configuración. Publicas una clave (pública) que cualquiera puede usar para proteger un mensaje para ti, y guardas otra clave (privada) que solo tú puedes usar para abrirlo. La matemática es elegante, pero la razón por la que importó es simple: cambió cómo se distribuyen los secretos.

Por qué los secretos compartidos no escalan

Imagina una tienda en línea con un millón de clientes. Con claves simétricas, la tienda necesitaría un secreto compartido distinto con cada cliente.

Eso crea preguntas confusas:

  • ¿Cómo entrega la tienda a cada cliente su clave secreta sin que alguien la robe?

  • ¿Qué ocurre cuando una clave se filtra: la sustituyes en todas partes?

  • ¿Cómo evitas enviar la clave por la misma red que intentas proteger?

Cuando la comunicación es uno a uno y fuera de línea, quizá intercambies un secreto en persona o por mensajería confiable. En la red abierta, ese enfoque falla.

La analogía del candado (caja cerrada)

Piensa en enviar un objeto valioso por correo. Con claves simétricas, tú y el destinatario debéis compartir primero la misma llave física.

Con claves públicas, el destinatario puede mandarte un candado abierto (su clave pública). Pones el objeto en una caja, cierras con ese candado y lo envías. Cualquiera puede sostener el candado, pero solo el destinatario tiene la llave que lo abre (su clave privada).

Eso es lo que internet necesitaba: una forma de intercambiar secretos con desconocidos, a escala, sin una contraseña preacordada.

RSA en contexto: un avance práctico de clave pública

La criptografía de clave pública no empezó con RSA. El gran cambio conceptual llegó en 1976, cuando Whitfield Diffie y Martin Hellman describieron cómo dos personas podían comunicarse de forma segura sin compartir antes un secreto en persona. Esa idea —separar la información “pública” de los secretos “privados”— marcó la dirección de todo lo que vino después.

Un año después (1977), Ron Rivest, Adi Shamir y Leonard Adleman presentaron RSA, y rápidamente se convirtió en el sistema de clave pública que la gente podía desplegar. No porque fuera la única idea ingeniosa, sino porque encajaba con las necesidades desordenadas de los sistemas reales: era sencillo de implementar, adaptable a muchos productos y fácil de estandarizar.

Lo que RSA habilitó (en términos sencillos)

RSA hizo utilizables dos capacidades críticas:

  • Cifrado hacia una clave pública: cualquiera puede cerrar un mensaje con tu clave pública; solo tú puedes abrirlo con tu clave privada.
  • Firmas digitales: puedes “firmar” datos con tu clave privada, y los demás pueden verificar la firma con tu clave pública.

Esos dos mecanismos parecen simétricos, pero resuelven problemas distintos. El cifrado protege la confidencialidad. Las firmas protegen la autenticidad e integridad: prueba de que un mensaje o una actualización de software realmente vino de quien dice venir.

Por qué RSA fue práctico

El poder de RSA no fue solo académico. Era implementable con los recursos informáticos de la época, y encajaba en productos como un componente, no como un prototipo de investigación.

Igualmente importante, RSA fue estandarizable e interoperable. A medida que surgieron formatos y APIs comunes (piensa en convenciones compartidas sobre tamaños de clave, relleno y manejo de certificados), los sistemas de distintos proveedores podían trabajar juntos.

Esa practicidad —más que cualquier detalle técnico puntual— ayudó a que RSA se convirtiera en un bloque de construcción por defecto para comunicación y comercio seguros.

RSA para cifrado: el plano para seguridad híbrida

El cifrado RSA es, en esencia, una forma de mantener un mensaje confidencial cuando solo conoces la clave pública del destinatario. Puedes publicar esa clave ampliamente y cualquiera puede usarla para cifrar datos que solo la clave privada correspondiente podrá descifrar.

Eso resuelve un problema práctico: no necesitas una reunión secreta ni una contraseña precompartida antes de empezar a proteger la información.

Por qué RSA rara vez cifra “todo el archivo”

Si RSA puede cifrar datos, ¿por qué no usarlo para todo —correos, fotos, exportaciones de bases de datos? Porque RSA es costoso computacionalmente y tiene límites estrictos de tamaño: solo puedes cifrar datos hasta cierta longitud (aproximada según el tamaño de la clave) y hacerlo repetidamente es lento frente a los algoritmos simétricos modernos.

Esa realidad impulsó uno de los patrones más importantes en criptografía aplicada: el cifrado híbrido.

Cifrado híbrido en un solo paso

En un diseño híbrido, RSA protege un secreto pequeño y un cifrado simétrico más rápido protege los datos principales:

  1. Tu dispositivo genera una clave de sesión aleatoria (una clave simétrica).
  2. Cifra los datos reales con esa clave de sesión (rápido).
  3. Cifra la clave de sesión con RSA usando la clave pública del destinatario (pequeño y manejable).
  4. El destinatario usa su clave privada RSA para recuperar la clave de sesión y luego descifra los datos.

Esta elección de diseño se trata principalmente de rendimiento y practicidad: el cifrado simétrico está hecho para velocidad en datos grandes, mientras que el cifrado de clave pública está hecho para un intercambio de claves seguro.

El patrón sobrevivió al intercambio de claves RSA

Muchos sistemas modernos prefieren métodos de intercambio de claves distintos (notablemente variantes efímeras de Diffie–Hellman en TLS) por mayor secreto hacia adelante y mejores características de rendimiento.

Pero el modelo de RSA —“clave pública para proteger un secreto de sesión, criptografía simétrica para la carga útil”— marcó la plantilla que la comunicación segura sigue usando hoy en día.

Firmas digitales: confianza que puedes verificar

Despliega sin complicaciones
Despliega y aloja tu app sin tener que unir una docena de herramientas y configuraciones.

Una firma digital es el equivalente en línea de sellar un documento con un sello que evidencia manipulaciones y, al mismo tiempo, una comprobación de identidad. Si incluso un carácter del mensaje firmado cambia, la firma deja de coincidir. Y si la firma verifica con la clave pública del firmante, tienes una fuerte evidencia sobre quién lo aprobó.

Firmar vs cifrar: dos promesas distintas

Es fácil confundir ambos porque a menudo van juntos, pero resuelven problemas distintos:

  • Cifrado protege la secrecía: solo quien tenga la clave adecuada puede leer el contenido.
  • Firmas digitales protegen la integridad y autenticidad: el contenido no fue alterado y fue aprobado por el poseedor de la clave de firma.

Puedes firmar un mensaje que cualquiera pueda leer (como un anuncio público). También puedes cifrar algo sin firmarlo (privado, pero sin saber realmente quién lo envió). Muchos sistemas reales hacen ambas cosas.

Por qué al comercio le interesó de inmediato

Una vez que RSA hizo prácticas las firmas de clave pública, las empresas pudieron trasladar la confianza de llamadas telefónicas y papel a datos verificables:

  • Pedidos y facturas: una orden de compra firmada puede verificarse automáticamente, reduciendo disputas por “eso no lo enviamos”.
  • Contratos y aprobaciones: flujos internos (finanzas, legal, compras) pueden registrar quién aprobó qué y cuándo.
  • Actualizaciones de software: versiones firmadas permiten a dispositivos y apps verificar que las actualizaciones vinieron del proveedor y no fueron modificadas en el camino —uno de los usos más importantes hoy.

Una nota prudente sobre “no repudio”

A menudo se dice que las firmas ofrecen no repudio —evitar que el firmante niegue creíblemente que firmó. En la práctica, es un objetivo, no una garantía. El robo de claves, cuentas compartidas, seguridad débil de dispositivos o políticas poco claras pueden ensuciar la atribución.

Las firmas digitales son evidencia potente, pero la responsabilidad en el mundo real también necesita buena gestión de claves, registros y procedimientos.

Preguntas frecuentes

¿Qué permitió realmente RSA que los enfoques criptográficos anteriores no conseguían?

RSA hizo que la criptografía de clave pública fuera práctica de desplegar: cualquiera podía usar una clave pública para cifrar datos para ti, y tú podías usar una clave privada para descifrarlos.

Igualmente importante, RSA soportó firmas digitales, que permiten verificar que los datos realmente vinieron de quien dicen y que no fueron alterados.

Esa combinación (cifrado + firmas) encajó en productos reales y pudo estandarizarse, lo que ayudó a su adopción.

¿Por qué no escalaba bien el cifrado simétrico para Internet?

La criptografía simétrica es rápida, pero requiere que ambas partes compartan ya la misma clave secreta.

A escala de internet, eso se convierte en problemas difíciles:

  • No puedes precompartir de forma segura secretos con cada sitio o cliente.
  • Si una clave compartida se filtra, su reemplazo es doloroso.
  • Existe el riesgo de enviar la clave por la misma red que intentas proteger.

La criptografía de clave pública (incluida RSA) cambió el problema de distribución permitiendo que la gente publique una clave pública abiertamente.

¿Qué es el “cifrado híbrido” y por qué se usa con RSA?

El cifrado híbrido es el patrón práctico donde la criptografía de clave pública protege un secreto pequeño y la criptografía simétrica protege los datos en bloque.

Flujo típico:

  1. Generar una clave de sesión simétrica aleatoria.

  2. Cifrar los datos con esa clave de sesión (rápido).

  3. Cifrar la clave de sesión con la clave pública del destinatario (pequeño).

  4. El destinatario descifra la clave de sesión con su clave privada y luego descifra los datos.

Esto existe porque RSA es más lento y tiene límites de tamaño, mientras que los cifrados simétricos están diseñados para datos grandes.

¿Cuál es la diferencia entre el cifrado RSA y las firmas digitales RSA?

El cifrado responde a: “¿Quién puede leer esto?”

La firma digital responde a: “¿Quién aprobó esto y fue modificado?”

En la práctica:

  • Puedes firmar un mensaje público para que cualquiera verifique su autenticidad.
  • Puedes cifrar un mensaje para que sólo el destinatario lo lea.

Muchos sistemas hacen ambas cosas para obtener confidencialidad y un origen/integridad fiables.

¿Por qué necesitan los sitios HTTPS certificados si las claves públicas pueden compartirse abiertamente?

Un certificado TLS es básicamente una tarjeta de identificación para un sitio web. Asocia un nombre de dominio (como example.com) con una clave pública y metadatos (por ejemplo, la organización en ciertos tipos de certificado y la fecha de caducidad).

Cuando tu navegador se conecta por HTTPS, el servidor presenta ese certificado para que el navegador verifique que está hablando con el dominio correcto antes de establecer la comunicación cifrada.

¿Cómo funciona en la práctica la “cadena de confianza” de las CA?

Los navegadores y sistemas operativos incluyen un conjunto de Autoridades de Certificación (CAs) raíz de confianza. La mayoría de los sitios usan una cadena:

  • El certificado del sitio (leaf) está firmado por una CA intermedia.
  • La intermedia está firmada por una CA raíz ya incluida en el navegador.

Durante una conexión HTTPS, el navegador verifica:

  • Las firmas en la cadena
  • Que el nombre de dominio coincida
  • El periodo de validez del certificado

Si esas comprobaciones pasan, el navegador acepta que la clave pública pertenece a ese dominio.

Si RSA fue tan importante, ¿por qué TLS moderno suele usar ECDHE?

En TLS moderno, el acuerdo de claves suele hacerse con Diffie–Hellman efímero (ECDHE) en lugar del transporte de claves RSA.

Razón principal: secreto hacia adelante.

  • Con ECDHE, si la clave a largo plazo del servidor se roba después, el tráfico pasado capturado sigue siendo difícil de descifrar.
  • Con el transporte de claves RSA antiguo, el tráfico capturado podría descifrarse si la clave privada del servidor se compromete más tarde.

RSA aún puede aparecer en TLS como certificado/firmas, pero el handshake ha pasado mayoritariamente a ECDHE para el acuerdo de claves.

¿Cuáles son las fallas más comunes en el mundo real relacionadas con TLS, RSA o certificados?

Fallas operacionales comunes incluyen:

  • Certificados caducados (causando interrupciones)
  • Claves privadas copiadas ampliamente (aumentando el riesgo de robo)
  • Configuraciones TLS débiles u obsoletas (protocolos/cifras antiguas)
  • Bibliotecas desactualizadas que pierden parches o validan certificados incorrectamente

Las matemáticas pueden estar bien, pero los sistemas reales fallan por manejo de claves, configuración y mantenimiento.

¿Qué significa “gestión de claves” y por qué suele ser más importante que el algoritmo?

La gestión de claves abarca el ciclo de vida de las claves criptográficas:

  • Generación: buena aleatoriedad, parámetros correctos
  • Almacenamiento: limitar accesos; dificultar la extracción; registrar usos
  • Rotación: reemplazo seguro según calendario y tras sospecha de exposición
  • Copia de seguridad/recuperación: restaurar sin crear una «copia maestra» fácil de clonar

Si un atacante roba una clave privada, puede descifrar datos protegidos (en algunos diseños) o suplantar servicios y firmar contenido malicioso: por eso los controles operativos alrededor de las claves son tan importantes como el algoritmo.

¿Cómo ayuda en la práctica la pila RSA/TLS/PKI al comercio en línea y los pagos?

Usa criptografía para proteger las conexiones y mensajes entre partes que no comparten una red privada:

  • HTTPS (TLS) protege los datos de pago en tránsito y ayuda a los usuarios a llegar al sitio real del comerciante.
  • Las llamadas internas (comerciante ↔ pasarela, servicio ↔ servicio) suelen usar mutual TLS y/o peticiones firmadas para demostrar autenticidad e integridad.
  • La tokenización reduce la exposición al almacenar tokens en lugar de números de tarjeta sin procesar.

La criptografía no resuelve por sí sola el fraude ni las disputas: esos requieren controles de riesgo y procesos, pero la criptografía hace mucho más difícil interceptar o manipular la tubería de pagos.

Related posts