08 ago 2025·8 min
Leonard Adleman y RSA: cómo Internet aprendió a confiar
Leonard Adleman ayudó a crear RSA, un sistema de clave pública que permitió HTTPS, la banca en línea y actualizaciones firmadas. Aprende cómo funciona y por qué importa.
Leonard Adleman ayudó a crear RSA, un sistema de clave pública que permitió HTTPS, la banca en línea y actualizaciones firmadas. Aprende cómo funciona y por qué importa.
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:
RSA se hizo famoso porque ayudó a que esas promesas fueran posibles a escala de Internet.
Has sentido el impacto de RSA incluso si nunca escuchaste el nombre. Está estrechamente ligado a cómo:
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.
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”.
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.
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.
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 criptosistema 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.
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.
La influencia de RSA va más allá de un algoritmo. Hizo viables a escala dos esenciales de Internet:
Esas ideas sustentan cómo HTTPS, la banca en línea y las actualizaciones firmadas se convirtieron en expectativas normales en lugar de excepciones.
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.
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.
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.
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:
RSA ayudó a hacer ambas cosas posibles, sentando las bases de cómo funciona la confianza en línea a escala.
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.
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.
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:
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.
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.
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.
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.
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.
RSA es famoso porque puede hacer dos tareas relacionadas pero diferentes: cifrado y firmas digitales. Confundirlas es una fuente común de errores.
El cifrado apunta principalmente a la confidencialidad. Las firmas digitales se centran en integridad + autenticidad.
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.
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:
Las firmas digitales aparecen en momentos cotidianos de “aprobación”:
El cifrado mantiene secretos; las firmas mantienen la confianza.
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.
Cuando visitas un sitio HTTPS, tu navegador y el servidor realizan una conversación de configuración llamada handshake TLS:
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.
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.
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.
Una sesión bancaria debe proteger tres cosas a la vez:
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Algunos patrones se repiten:
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.
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.
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 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.
La criptografía evoluciona por las mismas razones que otras técnicas de seguridad:
Verás alternativas en TLS y aplicaciones modernas:
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.
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.
RSA ayudó a que la confianza a escala de Internet fuera práctica al posibilitar la criptografía de clave pública, que soporta:
Esos bloques son centrales para HTTPS, la banca en línea y las actualizaciones de software firmadas.
Leonard Adleman ayudó a transformar RSA de una idea ingeniosa en un criptosistema que otros podían analizar y confiar. En la práctica eso significó poner a prueba las suposiciones, refinar la presentación y reforzar el argumento de por qué romper RSA debía ser difícil bajo modelos de ataque realistas.
Una clave pública está pensada para compartirse; la gente la usa para cifrar algo para ti o para verificar tus firmas.
Una clave privada debe mantenerse en secreto; se usa para descifrar lo cifrado hacia ti (en configuraciones de cifrado RSA) y para crear firmas que solo tú podrías producir.
Si la clave privada se filtra, los atacantes pueden suplantarte y/o descifrar secretos protegidos según el uso de la clave.
La seguridad de RSA se basa, a alto nivel, en un problema matemático unidireccional: multiplicar grandes primos es fácil, pero factorizar el número resultante en sus primos es extremadamente difícil con los tamaños de clave reales.
Las claves pública y privada están relacionadas matemáticamente, pero la relación está diseñada para que la clave pública no revele la privada de forma práctica.
Resuelven objetivos de confianza diferentes:
Una regla práctica:
En un flujo simplificado de HTTPS/TLS:
RSA puede usarse para autenticación (firmas) y, históricamente, también para proteger el secreto inicial de sesión en algunas configuraciones.
No. El candado indica principalmente que la conexión está cifrada y, por lo general, autenticada.
No garantiza:
Considera HTTPS como una capa necesaria de seguridad en el transporte, no como un veredicto absoluto de confianza.
Un certificado vincula una clave pública con una identidad (por ejemplo, un nombre de dominio). Los navegadores confían en esa vinculación porque una Autoridad de Certificación (CA) firma el certificado, y los navegadores/OS incluyen una lista de CAs de confianza.
Si despliegas servicios, planifica:
Las actualizaciones firmadas permiten que tu dispositivo verifique dos cosas:
Esto defiende contra ataques de “intercambio de paquete” (mirrors comprometidos, redes secuestradas, páginas de descarga que imitan a la original). Para una guía más profunda, consulta /blog/code-signing-basics.
Los fallos reales suelen ser operativos, no porque las matemáticas de RSA se hayan roto:
Medidas prácticas: protege las claves privadas (preferentemente en hardware), controla expiraciones, rota claves con criterio y monitoriza la emisión de certificados cuando sea posible.