Leonard Adleman y RSA: cómo Internet aprendió a confiar

Por qué RSA importa para la confianza cotidiana en Internet

Cuando la gente dice que “confía” en un sitio web o un servicio en línea, normalmente se refiere a tres cosas prácticas:

• Privacidad: los extraños no pueden leer tus mensajes, contraseñas o datos de pago mientras viajan por Internet.
• Identidad: realmente estás hablando con tu banco (o esa tienda), no con un impostor.
• Integridad: lo que recibes no ha sido cambiado silenciosamente—ya sea una página de inicio de sesión, una solicitud de transferencia bancaria o una actualización de software.

RSA se hizo famoso porque ayudó a que esas promesas fueran posibles a escala de Internet.

Sistemas cotidianos que habilitó RSA

Has sentido el impacto de RSA incluso si nunca escuchaste el nombre. Está estrechamente ligado a cómo:

• HTTPS protege muchas conexiones entre tu navegador y un sitio web (la idea del “candado”).
• La banca en línea pasó de “mejor no hacerlo por internet” a algo en lo que confían millones de personas.
• El software firmado y las actualizaciones pueden probar que vinieron del editor real y no fueron manipuladas en el trayecto.

El hilo común es la confianza sin tener que conocer personalmente (o preparar secretos con) cada servidor o proveedor de software con el que interactúas.

Qué esperar en esta guía

Este artículo mantiene las explicaciones sencillas: sin matemáticas pesadas y sin necesidad de formación en informática. Nos centraremos en la visión práctica del “por qué funciona”.

La idea clave: dos claves, dos roles

RSA popularizó un enfoque potente: en lugar de un secreto compartido, se usa una clave pública que puedes compartir abiertamente y una clave privada que guardas en secreto. Esa separación hace posible proteger la privacidad y probar la identidad en situaciones donde personas y sistemas nunca se han conocido antes.

El papel de Leonard Adleman en el descubrimiento de RSA

Leonard Adleman es la “A” en RSA, junto a Ron Rivest y Adi Shamir. Aunque Rivest y Shamir suelen recibir el crédito por la construcción central, la contribución de Adleman fue esencial: ayudó a convertir el sistema en algo que no solo era ingenioso, sino convincente—un algoritmo que la gente podía analizar, probar y en el que podía confiar.

Qué aportó Adleman al equipo

Una gran parte del papel de Adleman fue poner la idea a prueba. En criptografía, un esquema no vale porque suene plausible; vale porque sobrevive a ataques cuidadosos y escrutinio. Adleman trabajó en la validación, ayudó a refinar las suposiciones y contribuyó al encuadre inicial de por qué RSA debería ser difícil de romper.

Igualmente importante, ayudó a traducir “esto podría funcionar” en “esto es un cripto­sistema que otros pueden evaluar”. Esa claridad—hacer el diseño suficientemente comprensible para que la comunidad investigadora lo inspeccionara—fue crucial para su adopción.

Dónde encaja RSA en la historia de la criptografía

Antes de RSA, la comunicación segura dependía normalmente de que ambas partes ya compartieran una clave secreta. Ese enfoque funciona dentro de grupos cerrados, pero no escala cuando extraños necesitan comunicarse de forma segura (por ejemplo, un comprador y una tienda que se encuentran por primera vez).

RSA cambió esa historia al popularizar un sistema de clave pública práctico: puedes publicar una clave para que otros la usen mientras mantienes en secreto otra clave privada.

El impacto duradero

La influencia de RSA va más allá de un algoritmo. Hizo viables a escala dos esenciales de Internet:

• Cifrado, para proteger datos en tránsito
• Firmas digitales, para verificar que software y mensajes son auténticos

Esas ideas sustentan cómo HTTPS, la banca en línea y las actualizaciones firmadas se convirtieron en expectativas normales en lugar de excepciones.

El problema central que resolvió RSA: comunicación segura sin secretos compartidos

Antes de RSA, la comunicación segura significaba sobre todo cifrado de secreto compartido: ambas partes debían poseer la misma clave secreta de antemano. Eso funciona para un grupo pequeño, pero se desmorona cuando intentas ofrecer un servicio público usado por millones.

Por qué los secretos compartidos no escalan

Si cada cliente necesita una clave secreta única para hablar con un banco, el banco debe generar, entregar, almacenar, rotar y proteger una enorme cantidad de secretos. La parte más difícil no es la matemática, es la coordinación.

¿Cómo entregas de forma segura la clave secreta a cada persona? Mandarla por correo es lento y arriesgado. Decirla por teléfono puede ser interceptado o resultar en ingeniería social. Enviarla por Internet destruye el propósito, porque el canal es exactamente lo que intentas proteger.

Dos desconocidos, una conversación segura

Imagina dos desconocidos—por ejemplo, tú y una tienda en línea—que nunca se han conocido. Quieres enviar un pago de forma segura. Con cifrado de secreto compartido, necesitarías una clave privada que ambos ya conozcan. Pero no la conoces.

El avance de RSA fue permitir comunicación segura sin precompartir un secreto. En su lugar, puedes publicar una clave (clave pública) que cualquiera use para proteger un mensaje dirigido a ti, mientras guardas otra clave (clave privada) que solo tú posees.

Por qué “simplemente cifrar” no es suficiente

Incluso si pudieras cifrar mensajes, todavía necesitas saber a quién estás cifrando. De lo contrario, un atacante puede suplantar al banco o a la tienda, engañarte para usar su clave y leer o alterar todo a escondidas.

Por eso la comunicación segura en Internet necesita dos propiedades:

• Confidencialidad: los externos no pueden leer los datos.
• Autenticidad: puedes verificar con quién estás hablando (y que los mensajes no fueron manipulados).

RSA ayudó a hacer ambas cosas posibles, sentando las bases de cómo funciona la confianza en línea a escala.

Fundamentos de la criptografía de clave pública (sin jerga)

La criptografía de clave pública es una idea simple con grandes consecuencias: puedes cerrar algo para alguien sin acordar antes un secreto compartido. Ese es el cambio central que RSA ayudó a hacer práctico.

Clave pública vs. clave privada (en lenguaje llano)

Piensa en una clave pública como un candado que estás dispuesto a entregar a cualquiera. La gente puede usarlo para proteger un mensaje para ti—o (en sistemas de firma) para comprobar que algo realmente vino de ti.

Una clave privada es lo que debes mantener para ti. Es la llave que abre lo que se cerró con tu clave pública y también la que te permite crear firmas que solo tú podrías haber hecho.

Juntas, la clave pública y la privada forman un par de claves. Están conectadas matemáticamente, pero no son intercambiables. Compartir la clave pública es seguro porque conocerla no da una forma práctica de derivar la clave privada.

Dos trabajos principales: cifrado y firmas digitales

Cifrado trata sobre privacidad. Si alguien cifra un mensaje con tu clave pública, solo tu clave privada puede descifrarlo.

Firmas digitales tratan sobre confianza e integridad. Si firmas algo con tu clave privada, cualquiera con tu clave pública puede verificar dos cosas:

• que fue firmado por el poseedor de la clave privada
• que no fue alterado después de la firma

Por qué funciona (sin ecuaciones)

La seguridad no es magia—se apoya en problemas matemáticos difíciles que son fáciles de hacer en un sentido y extremadamente difíciles de revertir con los ordenadores actuales. Esa propiedad "unidireccional" es lo que hace seguro compartir la clave pública mientras la clave privada conserva su poder.

Cómo funciona RSA a alto nivel

RSA se basa en una asimetría simple: es fácil hacer la matemática “hacia adelante” para cerrar algo, pero extremadamente difícil revertir esa matemática para abrirlo—a menos que tengas un secreto especial.

La idea de una función unidireccional (con una trampa)

Piensa en RSA como una especie de candado matemático. Cualquiera puede usar la clave pública para cerrar un mensaje. Pero solo la persona que tiene la clave privada puede abrirlo.

Lo que hace esto posible es una relación cuidadosamente elegida entre las dos claves. Se generan juntas y, aunque están relacionadas, no puedes derivar de forma realista la clave privada mirando solo la pública.

Por qué importa la factorización

A alto nivel, RSA se apoya en que multiplicar números primos grandes es fácil, pero trabajar hacia atrás—descubrir qué primos se multiplicaron—es extraordinariamente difícil cuando los números son enormes.

Para números pequeños, factorizar es rápido. Para los tamaños usados en claves RSA reales (miles de bits), los mejores métodos conocidos todavía requieren una cantidad impráctica de tiempo y recursos computacionales. Esa propiedad de “difícil de revertir” impide que los atacantes reconstruyan la clave privada.

El flujo básico

1. Generar claves: tu dispositivo crea un par: clave pública y clave privada.
2. Publicar la clave pública: puede compartirse abiertamente—en un sitio web, en un certificado o en una app.
3. Proteger la clave privada: debe mantenerse en secreto. Si se filtra, el mecanismo queda comprometido.

Un detalle práctico que muchos pasan por alto

RSA normalmente no se usa para cifrar archivos grandes o mensajes largos directamente. En su lugar, protege secretos pequeños—principalmente una clave de sesión generada aleatoriamente. Esa clave de sesión cifra los datos reales usando cifrado simétrico más rápido, que es mejor para tráfico a granel.

Cifrado vs firmas digitales: dos trabajos distintos

RSA es famoso porque puede hacer dos tareas relacionadas pero diferentes: cifrado y firmas digitales. Confundirlas es una fuente común de errores.

Tres objetivos: confidencialidad, integridad, autenticidad

• Confidencialidad significa “solo la persona prevista puede leerlo.” Ejemplo: envías tu número de cuenta al sitio del banco y no quieres que nadie más lo vea.
• Integridad significa “no fue cambiado en el camino.” Ejemplo: un atacante no debería poder convertir “transferir $50” en “transferir $50,000.”
• Autenticidad significa “realmente vino de quien dice ser.” Ejemplo: quieres saber si un correo o una actualización provino de tu banco o un proveedor de confianza.

El cifrado apunta principalmente a la confidencialidad. Las firmas digitales se centran en integridad + autenticidad.

RSA para cifrado: proteger un mensaje (o, en la práctica, una clave)

Con cifrado RSA, alguien usa tu clave pública para cerrar algo de modo que solo tu clave privada pueda abrirlo.

En la práctica, RSA suele usarse para proteger una clave de sesión aleatoria. Esa clave luego cifra los datos a granel de forma eficiente.

RSA para firmas: probar quién creó algo y que no fue alterado

Con firmas RSA, la dirección se invierte: el emisor usa su clave privada para crear una firma, y cualquiera con la clave pública puede verificar:

• ¿Proviene realmente del titular de la clave privada? (autenticidad)
• ¿Se ha cambiado algo desde que se firmó? (integridad)

Por qué las firmas importan en la vida real

Las firmas digitales aparecen en momentos cotidianos de “aprobación”:

• Aprobación de transacciones: un banco puede firmar mensajes para que tu app confíe en las instrucciones que recibe.
• Descargas: un instalador firmado ayuda a tu equipo a verificar que proviene del publicador real.
• Actualizaciones: las actualizaciones firmadas evitan que atacantes inserten versiones maliciosas, incluso si pueden manipular el canal de entrega.

El cifrado mantiene secretos; las firmas mantienen la confianza.

RSA y HTTPS: qué ocurre cuando ves el candado

El candado en tu navegador es un atajo para una idea: tu conexión con este sitio web está cifrada y (por lo general) autenticada. Significa que otras personas en la red—por ejemplo, alguien en una Wi‑Fi pública—no pueden leer ni cambiar silenciosamente lo que tu navegador y el sitio se envían.

No significa que el sitio sea “seguro” en todos los sentidos. El candado no puede decirte si una tienda es honesta, si una descarga es malware o si escribiste el dominio correcto. Tampoco garantiza que el sitio vaya a proteger tus datos una vez que lleguen a sus servidores.

Un apretón de manos TLS simplificado (lo que realmente hace tu navegador)

Cuando visitas un sitio HTTPS, tu navegador y el servidor realizan una conversación de configuración llamada handshake TLS:

• El servidor envía un certificado. Incluye la clave pública del sitio y el nombre de dominio que afirma ser.
• Tu navegador comprueba la identidad. Verifica que el certificado sea válido para ese dominio, que no esté caducado y que esté firmado por una Autoridad de Certificación (CA) de confianza.
• Crean claves de sesión. Una vez que el navegador está satisfecho de que habla con la parte correcta, ambas partes acuerdan claves simétricas temporales para la sesión.

Dónde entra RSA

Históricamente, RSA se usó con frecuencia para intercambiar la clave de sesión (el navegador cifra un secreto con la clave pública del servidor). En muchas configuraciones TLS modernas, RSA se usa principalmente para autenticación mediante firmas (probar que el servidor controla la clave privada), mientras que el acuerdo de claves se realiza con otros métodos.

Por qué tus datos no se cifran con RSA

RSA es excelente para establecer confianza y proteger piezas pequeñas de información durante la configuración, pero es lento comparado con el cifrado simétrico moderno. Tras el handshake, HTTPS cambia a algoritmos simétricos rápidos para las cargas de página, inicios de sesión y transacciones bancarias.

Cómo HTTPS con RSA hizo práctica la banca en línea

La banca en línea tiene una promesa simple: debes poder iniciar sesión, revisar saldos y mover dinero sin que otra persona aprenda tus credenciales—o cambie silenciosamente lo que envías.

Qué necesitaban los bancos que la web hiciera

Una sesión bancaria debe proteger tres cosas a la vez:

• Inicios de sesión: tu contraseña (y otros secretos) no deben exponerse en tránsito.
• Transacciones: importes y cuentas de destino deben llegar exactamente como los enviaste.
• Datos personales: detalles de cuenta, direcciones y mensajes no deben ser legibles por quien vigile la red.

Sin HTTPS, cualquiera en la misma Wi‑Fi, un router comprometido o un operador de red malicioso podría espiar o manipular el tráfico.

Cómo HTTPS hizo que fuera lo bastante seguro para confiar

HTTPS (mediante TLS) asegura la conexión para que los datos entre tu navegador y el banco estén cifrados y con integridad verificada. En términos prácticos, eso significa:

• Los atacantes no pueden leer tu tráfico (no hay robo fácil de contraseñas por intercepción).
• Los atacantes no pueden alterar silenciosamente las solicitudes (no hay “cambiar $50 por $5,000” en vuelo).

El papel histórico de RSA fue crucial porque ayudó a resolver el problema del “primer contacto”: establecer una sesión segura sobre una red insegura.

Por qué la identidad importa tanto como el cifrado

El cifrado por sí solo no basta si estás cifrando con la parte equivocada. La banca en línea solo funciona si el navegador puede decir que está hablando con el banco real, no con un sitio impostor o con un hombre en el medio.

Capas extra (útiles, no reemplazos)

Los bancos siguen añadiendo MFA, comprobaciones de dispositivo y monitorización de fraude. Reducen el daño cuando se roban credenciales—pero no reemplazan a HTTPS. Funcionan mejor como respaldos sobre una conexión que ya es privada y resistente a manipulaciones.

Distribución segura de software: por qué importan las actualizaciones firmadas

Las actualizaciones de software son tanto un problema de confianza como técnico. Incluso si una app está bien escrita, un atacante puede atacar el paso de entrega—sustituyendo un instalador legítimo por uno modificado o insertando una actualización manipulada en la cadena entre el editor y el usuario. Sin una forma fiable de autenticar lo que descargaste, “actualización disponible” puede convertirse en una puerta fácil.

El ataque simple: intercambiar el paquete

Si las actualizaciones solo están protegidas por un enlace de descarga, un atacante que comprometa un mirror, secuestre una conexión de red o engañe al usuario para visitar una página clónica puede servir un archivo diferente con el mismo nombre. El usuario puede instalarlo normalmente y el daño puede ser “silencioso”: malware incluido en la actualización, puertas traseras añadidas al programa o ajustes de seguridad debilitados.

Firma de código: probar quién lo construyó (y que no fue modificado)

La firma de código usa criptografía de clave pública (incluyendo RSA en muchos sistemas) para adjuntar una firma digital a un instalador o paquete de actualización.

El publicador firma el software con una clave privada. Tu dispositivo (u OS) verifica esa firma usando la clave pública del publicador—a menudo entregada mediante una cadena de certificados. Si cambia incluso un byte, la verificación falla. Esto desplaza la confianza de “¿de dónde lo descargué?” a “¿puedo verificar quién lo creó y que está intacto?”

En las canalizaciones modernas de entrega de apps, estas mismas ideas se extienden más allá de instaladores a llamadas de API, artefactos de compilación y despliegues. Por ejemplo, plataformas como Koder.ai (una plataforma de vibe-coding para enviar apps web, backend y móviles desde una interfaz de chat) aún se apoyan en los mismos fundamentos: HTTPS/TLS para datos en tránsito, manejo cuidadoso de certificados para dominios personalizados y flujos de trabajo prácticos de tipo rollback (instantáneas y puntos de restauración) para reducir el riesgo al desplegar cambios.

Qué significa esto para los usuarios cotidianos

Las actualizaciones firmadas reducen las oportunidades de manipulación sin detectar. Los usuarios reciben advertencias más claras cuando algo va mal y los sistemas de actualización automáticos pueden rechazar archivos alterados antes de ejecutarlos. No garantiza que el software esté libre de errores, pero es una defensa poderosa contra la suplantación y la manipulación en la cadena de suministro.

Para profundizar en cómo firmas, certificados y verificación encajan, consulta /blog/code-signing-basics.

Certificados y PKI: cómo las claves públicas se vuelven confiables

Si RSA te da una clave pública, surge una pregunta natural: ¿de quién es esa clave pública?

Un certificado es la respuesta de Internet. Es un pequeño archivo firmado que conecta una clave pública con una identidad—como un nombre de sitio (example.com), una organización o un publicador de software. Piensa en él como una tarjeta de identificación para una clave: dice “esta clave pertenece a este nombre” e incluye detalles como el propietario, la clave pública y fechas de validez.

Autoridades de certificación: conectores de confianza, no magia

Los certificados importan porque están firmados por otro. Ese “otro” suele ser una Autoridad de Certificación (CA).

Una CA es un tercero que verifica ciertas pruebas (que pueden ir desde control de dominio básico hasta verificación empresarial más profunda) y luego firma el certificado. Tu navegador u operativo trae integrada una lista de CAs de confianza. Cuando visitas un sitio con HTTPS, tu dispositivo usa esa lista para decidir si acepta la declaración del certificado.

El sistema no es perfecto: las CAs pueden cometer errores y los atacantes pueden intentar engañarlas o comprometerlas. Pero crea una cadena práctica de confianza que funciona a escala global.

Caducidad y revocación: qué ocurre cuando algo cambia

Los certificados expiran a propósito. Las vidas cortas limitan el daño si una clave se roba e incentivan mantenimiento regular.

Los certificados también pueden revocarse antes de expirar. La revocación es una forma de decir “dejen de confiar en este certificado”, por ejemplo si una clave privada pudo haberse filtrado o si se emitió de forma incorrecta. Los dispositivos pueden comprobar el estado de revocación (con fiabilidad y rigor variables), por lo que la higiene de claves sigue siendo importante.

Consejos prácticos de gestión de claves

Mantén tu clave privada privada: almacénala en un lugar seguro, restringe el acceso y evita copiarla entre sistemas salvo que sea necesario.

Rota claves cuando haga falta—tras un incidente, durante actualizaciones planeadas o por políticas. Y lleva un control de las fechas de expiración para que las renovaciones no sean emergencias de última hora.

Límites, riesgos y malentendidos comunes sobre RSA

RSA es una idea fundamental, pero no es un escudo mágico. La mayoría de las fallas reales no ocurren porque alguien “resolvió RSA”—ocurren porque fallan los sistemas alrededor de RSA.

Modos de fallo comunes (lo que realmente sale mal)

Algunos patrones se repiten:

• Claves débiles: usar claves RSA demasiado cortas o configuraciones obsoletas reduce el costo del ataque.
• Almacenamiento pobre de claves: claves privadas dejadas en un servidor comprometido, copiadas en backups o subidas a un repositorio pueden ser robadas sin romper ninguna matemática.
• Phishing y compromiso de endpoints: si un atacante engaña a una persona para aprobar un inicio de sesión o instala malware en un dispositivo, RSA no puede ayudar; el cifrado no arregla un endpoint hackeado.
• Certificados emitidos incorrectamente: si una CA emite un certificado equivocado, los usuarios pueden ser redirigidos a un atacante pese a ver HTTPS “válido”.

Por qué la longitud de clave y la aleatoriedad importan

La seguridad de RSA depende de generar claves suficientemente grandes y verdaderamente impredecibles. Buena aleatoriedad es esencial: si la generación de claves usa una fuente aleatoria débil, los atacantes pueden reproducir o acotar las claves posibles. Igualmente, la longitud de la clave importa porque las mejoras en capacidad de cómputo y técnicas matemáticas reducen continuamente la seguridad de claves pequeñas.

RSA no es “demasiado lento”, pero se usa selectivamente

Las operaciones RSA son más costosas que las alternativas modernas, por eso muchos protocolos usan RSA con moderación—a menudo para autenticación o intercambio de un secreto temporal, y luego cambian a cifrado simétrico más rápido para los datos a granel.

El mayor malentendido: “RSA por sí sola te hace seguro”

La seguridad funciona mejor como defensas en profundidad: protege las claves privadas (idealmente en hardware), monitoriza la emisión de certificados, parchea sistemas, usa autenticación resistente al phishing y diseña rotación de claves segura. RSA es una herramienta en la cadena, no la cadena entera.

RSA hoy: dónde encaja aún y qué se suele usar en su lugar

RSA es una de las herramientas criptográficas más soportadas en Internet. Incluso si un servicio ya no “prefiere” RSA, a menudo mantiene compatibilidad porque está en todas partes: dispositivos antiguos, sistemas empresariales de larga duración e infraestructuras de certificados construidas durante años.

Por qué los sistemas evolucionan más allá de RSA

La criptografía evoluciona por las mismas razones que otras técnicas de seguridad:

• Velocidad y eficiencia: las operaciones RSA pueden ser relativamente lentas y requieren claves grandes. Métodos más nuevos ofrecen la misma seguridad con claves más pequeñas y handshakes más rápidos.
• Nuevas amenazas y márgenes de seguridad: conforme mejora la investigación, la comunidad reevalúa qué es lo más seguro y fácil de implementar correctamente.
• Diseños mejores para uso moderno: la web necesita conexiones rápidas, buen rendimiento móvil y servicios a gran escala—lo que empuja estándares hacia algoritmos que encajan con esas limitaciones.

Qué se usa junto a RSA o en su lugar

Verás alternativas en TLS y aplicaciones modernas:

• ECDSA y Ed25519 para firmas digitales (probar que “este servidor/app es auténtico”). Suelen ser más rápidas y usar claves más pequeñas que RSA.
• ECDH para intercambio de claves (acordar un secreto compartido para empezar una sesión). Esto es una gran razón por la que muchas conexiones HTTPS ya no dependen de RSA para el paso principal de "bloquear el secreto".

Llanamente: RSA puede hacer cifrado y firmas, pero los sistemas modernos a menudo dividen el trabajo—usando un método optimizado para firmas y otro para establecer claves de sesión.

¿Entonces RSA está obsoleto?

No. RSA sigue siendo ampliamente compatible y es una opción válida en muchos contextos, especialmente donde la compatibilidad es crucial o donde las prácticas de gestión de claves y certificados existentes están basadas en RSA. La “mejor” opción depende de factores como soporte de dispositivos, necesidades de rendimiento, requisitos de cumplimiento y cómo se almacenan y rotan las claves.

Si quieres ver cómo aparecen estas elecciones en conexiones HTTPS reales, el siguiente paso es: /blog/ssl-tls-explained.