08 de ago. de 2025·8 min
Leonard Adleman e RSA: Como a Internet Aprendeu a Confiar
Leonard Adleman ajudou a criar o RSA, um sistema de chave pública que viabilizou HTTPS, bancos online e atualizações assinadas. Saiba como funciona e por que importa.
Leonard Adleman ajudou a criar o RSA, um sistema de chave pública que viabilizou HTTPS, bancos online e atualizações assinadas. Saiba como funciona e por que importa.
Quando as pessoas dizem que “confiam” em um site ou serviço online, normalmente querem três coisas práticas:
O RSA ficou famoso porque ajudou a tornar essas promessas possíveis em escala na internet.
Você já sentiu o impacto do RSA mesmo que nunca tenha ouvido o nome. Ele está intimamente ligado a como:
O fio condutor é confiança sem precisar conhecer pessoalmente (ou combinar segredos com) cada servidor e fornecedor de software com quem você interage.
Este artigo mantém as explicações simples: sem matemática pesada e sem necessidade de formação em ciência da computação. Focaremos na visão prática do “por que funciona”.
O RSA popularizou uma abordagem poderosa: em vez de um segredo compartilhado, usa-se uma chave pública que pode ser divulgada abertamente e uma chave privada que você guarda em segredo. Essa separação torna possível proteger a privacidade e provar identidade em situações onde pessoas e sistemas nunca se encontraram antes.
Leonard Adleman é o “A” do RSA, ao lado de Ron Rivest e Adi Shamir. Embora Rivest e Shamir sejam frequentemente creditados pela construção central, a contribuição de Adleman foi essencial: ele ajudou a moldar o sistema em algo que não era apenas inteligente, mas convincente — um algoritmo que as pessoas podiam analisar, testar e confiar.
Uma parte importante do papel de Adleman foi testar a ideia sob pressão. Em criptografia, um esquema não vale por parecer plausível; vale por resistir a ataques e escrutínio cuidadosos. Adleman trabalhou na validação, ajudou a refinar suposições e contribuiu para a estruturação inicial do argumento sobre por que o RSA deveria ser difícil de quebrar.
Igualmente importante, ele ajudou a traduzir um “isso pode funcionar” em “isto é um criptossistema que outros podem avaliar”. Essa clareza — tornar o design compreensível o suficiente para a comunidade de pesquisa inspecionar — foi crucial para a adoção.
Antes do RSA, a comunicação segura normalmente dependia de ambas as partes já compartilharem uma chave secreta. Essa abordagem funciona em grupos fechados, mas não escala quando estranhos precisam se comunicar com segurança (por exemplo, um comprador e um site que se encontram pela primeira vez).
O RSA mudou essa história ao popularizar um sistema de criptografia de chave pública prático: você pode publicar uma chave para outros usarem, enquanto mantém uma chave privada em segredo.
A influência do RSA vai além de um algoritmo. Ele tornou possíveis em escala duas necessidades essenciais da internet:
Essas ideias sustentam como HTTPS, bancos online e atualizações assinadas se tornaram expectativas normais em vez de exceções raras.
Antes do RSA, comunicação segura significava principalmente criptografia com segredo compartilhado: ambos os lados precisavam possuir a mesma chave secreta antes do contato. Isso funciona para um grupo pequeno, mas desmorona quando se tenta executar um serviço público usado por milhões.
Se cada cliente precisa de uma chave secreta única para falar com um banco, o banco precisa gerar, distribuir, armazenar, rotacionar e proteger um enorme número de segredos. A parte mais difícil não é a matemática — é a coordenação.
Como entregar a chave secreta com segurança para cada pessoa em primeiro lugar? Enviar pelo correio é lento e arriscado. Dizer por telefone pode ser interceptado ou alvo de engenharia social. Enviar pela internet derrota o propósito, porque o canal é exatamente o que você está tentando proteger.
Imagine dois estranhos — você e uma loja online — que nunca se encontraram. Você quer enviar um pagamento com segurança. Com criptografia de segredo compartilhado, seria preciso uma chave privada que ambos já conhecessem. Mas vocês não conhecem.
A inovação do RSA foi permitir comunicação segura sem pré-compartilhar um segredo. Em vez disso, você pode publicar uma chave (a chave pública) que qualquer pessoa use para proteger uma mensagem para você, enquanto mantém outra chave (a chave privada) só sua.
Mesmo se você pudesse criptografar mensagens, ainda precisa saber para quem está criptografando. Caso contrário, um atacante pode se passar pelo banco ou pela loja, enganar você para usar a chave dele e, silenciosamente, ler ou alterar tudo.
Por isso a comunicação segura na internet precisa de duas propriedades:
O RSA ajudou a viabilizar ambas, lançando a base de como a confiança online funciona em escala.
Criptografia de chave pública é uma ideia simples com grandes consequências: você pode trancar algo para alguém sem antes combinar um segredo. Essa é a mudança central que o RSA ajudou a tornar prática.
Pense na chave pública como um cadeado que você está feliz em distribuir a qualquer pessoa. As pessoas podem usá-lo para proteger uma mensagem para você — ou (em sistemas de assinatura) para verificar que algo realmente veio de você.
A chave privada é a única coisa que você deve manter para si. É a chave que abre o que foi trancado com sua chave pública, e também permite criar assinaturas que só você poderia ter feito.
Juntas, a chave pública e a chave privada formam um par de chaves. Elas são matematicamente conectadas, mas não intercambiáveis. Compartilhar a chave pública é seguro porque conhecê-la não dá a alguém uma maneira prática de derivar a chave privada.
Criptografia trata da privacidade. Se alguém criptografa uma mensagem com sua chave pública, somente sua chave privada pode descriptografá-la.
Assinaturas digitais tratam de confiança e integridade. Se você assina algo com sua chave privada, qualquer pessoa com sua chave pública pode verificar duas coisas:
A segurança não é mágica — depende de problemas matemáticos difíceis que são fáceis de executar em uma direção e extremamente difíceis de reverter com computadores atuais. Essa propriedade “unidirecional” é o que torna seguro divulgar a chave pública enquanto mantém a chave privada poderosa.
O RSA se baseia numa assimetria simples: é fácil fazer a matemática “para frente” para travar algo, mas extremamente difícil reverter essa matemática para destravar — a não ser que você tenha um segredo especial.
Pense no RSA como um cadeado matemático. Qualquer um pode usar a chave pública para trancar uma mensagem. Mas só a pessoa com a chave privada consegue destrancá‑la.
O que torna isso possível é uma relação cuidadosamente escolhida entre as duas chaves. Elas são geradas juntas, e embora relacionadas, não é realista derivar a chave privada apenas observando a pública.
Em alto nível, o RSA apoia‑se no fato de que multiplicar números primos grandes é fácil, mas descobrir quais primos foram multiplicados (fatorar) é extremamente difícil quando os números são enormes.
Para números pequenos, fatorar é rápido. Para os tamanhos usados em chaves RSA reais (milhares de bits), os melhores métodos ainda exigem tempo e poder computacional impraticáveis. Essa característica “difícil de reverter” impede que atacantes reconstruam a chave privada.
O RSA geralmente não é usado para criptografar arquivos grandes ou mensagens longas diretamente. Em vez disso, costuma proteger segredos pequenos — especialmente uma chave de sessão gerada aleatoriamente. Essa chave de sessão então criptografa os dados reais usando criptografia simétrica, que é mais adequada para tráfego em massa.
O RSA é famoso porque pode desempenhar duas funções relacionadas — mas muito diferentes —: criptografia e assinaturas digitais. Misturá‑las é fonte comum de confusão.
Criptografia mira principalmente a confidencialidade. Assinaturas digitais almejam integridade + autenticidade.
Com criptografia RSA, alguém usa sua chave pública para travar algo de forma que somente sua chave privada possa destravar.
Na prática, o RSA costuma proteger uma semente pequena, como uma chave de sessão, que então criptografa os dados em massa de forma eficiente.
Com assinaturas RSA, o sentido inverte: o remetente usa sua chave privada para criar uma assinatura, e qualquer pessoa com a chave pública pode verificar:
Assinaturas digitais aparecem em momentos cotidianos de “aprovação”:
A criptografia protege segredos; as assinaturas protegem a confiança.
O cadeado no navegador é um atalho para uma ideia: sua conexão com este site está criptografada e (geralmente) autenticada. Significa que outras pessoas na rede — como alguém numa rede Wi‑Fi pública — não conseguem ler ou alterar silenciosamente o que seu navegador e o site trocam.
Não significa que o site é “seguro” em todo sentido. O cadeado não diz se uma loja é honesta, se um download é malware ou se você digitou o domínio correto. Também não garante que o site protegerá seus dados depois de chegarem aos servidores dele.
Quando você visita um site HTTPS, navegador e servidor realizam uma conversa de configuração chamada handshake TLS:
Historicamente, o RSA era frequentemente usado para trocar a chave de sessão (o navegador criptografava um segredo com a chave pública do servidor). Em muitas configurações modernas de TLS, o RSA é usado principalmente para autenticação via assinaturas (provar que o servidor controla a chave privada), enquanto o acordo de chave é feito por outros métodos.
O RSA é ótimo para estabelecer confiança e proteger pequenos pedaços de dados durante a configuração, mas é lento comparado à criptografia simétrica. Depois do handshake, o HTTPS alterna para algoritmos simétricos rápidos para as cargas úteis reais — páginas, logins e transações bancárias.
O banco online tem uma promessa simples: você deve poder entrar, ver saldos e movimentar dinheiro sem que outra pessoa aprenda suas credenciais — ou altere silenciosamente o que você envia.
Uma sessão bancária tem que proteger três coisas ao mesmo tempo:
Sem HTTPS, qualquer pessoa na mesma rede Wi‑Fi, um roteador comprometido ou um operador de rede malicioso poderia potencialmente escutar ou meter a mão no tráfego.
O HTTPS (via TLS) protege a conexão para que os dados entre seu navegador e o banco estejam criptografados e com verificação de integridade. Na prática, isso significa:
O papel histórico do RSA foi crucial aqui porque ajudou a resolver o problema do “primeiro contato”: estabelecer uma sessão segura numa rede insegura.
A criptografia sozinha não basta se você estiver criptografando para a parte errada. O banco online só funciona se o navegador conseguir dizer que está falando com o banco real, não com um site impostor ou um homem‑no‑meio.
Os bancos ainda adicionam MFA, verificações de dispositivo e monitoramento antifraude. Isso reduz danos quando credenciais são roubadas — mas não substitui o HTTPS. Essas medidas funcionam melhor como salvaguardas sobre uma conexão que já é privada e resistente a adulterações.
Atualizações de software são um problema de confiança tanto quanto técnico. Mesmo que um app seja bem escrito, um atacante pode mirar na etapa de entrega — trocando um instalador legítimo por um modificado ou enfiando uma atualização adulterada no caminho entre o editor e o usuário. Sem uma forma confiável de autenticar o que você baixou, “atualização disponível” pode virar uma porta de entrada fácil.
Se atualizações só forem protegidas por um link de download, um atacante que compromete um mirror, sequestra uma conexão de rede ou engana um usuário para visitar uma página falsa pode servir um arquivo diferente com o mesmo nome. O usuário pode instalar normalmente, e o dano pode ser “silencioso”: malware junto com a atualização, backdoors incluídos no programa ou configurações de segurança enfraquecidas.
A assinatura de código usa criptografia de chave pública (incluindo RSA em muitos sistemas) para anexar uma assinatura digital a um instalador ou pacote de atualização.
O editor assina o software com uma chave privada. Seu dispositivo (ou sistema operacional) verifica essa assinatura usando a chave pública do editor — frequentemente entregue via cadeia de certificados. Se mesmo um byte for alterado, a verificação falha. Isso desloca a confiança de “de onde baixei?” para “consigo verificar quem criou e que está íntegro?”
Em pipelines modernas de entrega de apps, essas ideias se estendem além de instaladores para chamadas de API, artefatos de build e rollouts de implantação. Por exemplo, plataformas como Koder.ai (uma plataforma vibe-coding para enviar apps web, backend e mobile a partir de uma interface de chat) ainda dependem das mesmas fundações: HTTPS/TLS para dados em trânsito, manuseio cuidadoso de certificados para domínios personalizados e fluxos práticos de rollback (snapshots e pontos de restauração) para reduzir riscos ao publicar mudanças.
Atualizações assinadas reduzem oportunidades de adulteração sem aviso. Usuários recebem avisos mais claros quando algo está errado, e sistemas de atualização automáticos podem rejeitar arquivos alterados antes de executá‑los. Não é garantia de que o software esteja livre de bugs, mas é uma defesa poderosa contra impersonação e manipulação da cadeia de suprimentos.
Para aprofundar como assinaturas, certificados e verificação se encaixam, veja /blog/code-signing-basics.
Se o RSA te dá uma chave pública, uma questão natural surge: de quem é essa chave pública?
Um certificado é a resposta da internet. É um pequeno arquivo assinado que conecta uma chave pública a uma identidade — como um nome de site (example.com), uma organização ou um editor de software. Pense nele como um documento de identidade para uma chave: diz “esta chave pertence a este nome” e inclui detalhes como o proprietário, a chave pública e datas de validade.
Os certificados importam porque são assinados por outra pessoa. Esse “alguém” costuma ser uma Autoridade Certificadora (CA).
Uma CA é um terceiro que verifica certas provas (que podem ir desde controle de domínio básico até verificações mais profundas de empresa) e então assina o certificado. Seu navegador ou sistema operacional vem com uma lista integrada de CAs confiáveis. Ao visitar um site via HTTPS, seu dispositivo usa essa lista para decidir se aceita a afirmação do certificado.
Esse sistema não é perfeito: CAs podem errar, e atacantes podem tentar enganá‑las ou comprometê‑las. Mas cria uma cadeia prática de confiança que funciona em escala global.
Certificados expiram de propósito. Vidas úteis curtas limitam danos se uma chave for roubada e incentiva manutenção regular.
Certificados também podem ser revogados antes do vencimento. Revogação é uma forma de dizer “parem de confiar neste certificado”, por exemplo se uma chave privada pode ter vazado ou se o certificado foi emitido incorretamente. Dispositivos podem checar o status de revogação (com níveis variados de confiabilidade e rigor), por isso a higiene de chaves continua importante.
Mantenha sua chave privada privada: armazene‑a em cofre de chaves seguro, restrinja acessos e evite copiá‑la entre sistemas sem necessidade.
Roteie chaves quando necessário — após um incidente, durante atualizações planejadas ou quando a política exigir. E rastreie datas de expiração para que renovações não se tornem emergências de última hora.
O RSA é uma ideia fundamental, mas não é um escudo mágico. A maioria das quebras no mundo real não ocorre porque alguém “quebrou o RSA” — ocorre porque os sistemas ao redor do RSA falham.
Alguns padrões reaparecem com frequência:
A segurança do RSA depende de gerar chaves suficientemente grandes e verdadeiramente imprevisíveis. Boa aleatoriedade é essencial: se a geração usar uma fonte fraca, atacantes podem reproduzir ou reduzir as chaves possíveis. Da mesma forma, tamanho da chave importa porque avanços em poder computacional e técnicas matemáticas diminuem continuamente a margem de segurança para chaves pequenas.
Operações RSA são mais pesadas que alternativas modernas, por isso muitos protocolos usam o RSA com parcimônia — frequentemente para autenticação ou troca de um segredo temporário, e então trocam para criptografia simétrica mais rápida para o tráfego em massa.
Segurança funciona melhor como defesa em profundidade: proteja chaves privadas (idealmente em hardware), monitore emissão de certificados, atualize sistemas, use autenticação resistente a phishing e projete rotações seguras de chaves. O RSA é uma ferramenta na cadeia — não a cadeia inteira.
O RSA é uma das ferramentas criptográficas mais suportadas na internet. Mesmo que um serviço não “prefira” RSA hoje, muitas vezes mantém compatibilidade porque está por toda parte: dispositivos antigos, sistemas empresariais de longa duração e infraestruturas de certificados construídas ao longo dos anos.
A criptografia evolui pelas mesmas razões que outras tecnologias de segurança:
Você verá alternativas comuns em TLS e aplicações modernas:
Em resumo: o RSA pode fazer encriptação e assinaturas, mas sistemas modernos frequentemente dividem o trabalho — usando um método otimizado para assinaturas e outro otimizado para estabelecer chaves de sessão.
Não. O RSA continua amplamente suportado e é uma escolha válida em muitos contextos, especialmente onde compatibilidade é crucial ou onde práticas existentes de gerenciamento de chaves e certificados já o adotaram. A “melhor” opção depende de fatores como suporte a dispositivos, necessidades de desempenho, requisitos de conformidade e como as chaves são armazenadas e rotacionadas.
Se quiser ver como essas escolhas aparecem em conexões HTTPS reais, o próximo passo é: /blog/ssl-tls-explained.
RSA ajudou a tornar prática a confiança em escala na internet ao viabilizar a criptografia de chave pública, que oferece:
Esses blocos são centrais para HTTPS, banco online e atualizações de software assinadas.
Leonard Adleman ajudou a transformar o RSA de uma ideia engenhosa em um criptossistema que outros poderiam analisar e confiar. Na prática, isso significou submeter hipóteses a testes, refinar a apresentação e fortalecer o argumento sobre por que seria difícil quebrar o RSA em cenários de ataque realistas.
Uma chave pública é para ser compartilhada; as pessoas a usam para criptografar algo para você ou para verificar suas assinaturas.
Uma chave privada deve ficar em segredo; é usada para descriptografar o que foi criptografado para você (em esquemas de encriptação RSA) e para criar assinaturas que só você poderia produzir.
Se a chave privada vazar, atacantes podem se passar por você e/ou descriptografar segredos dependendo de como a chave é usada.
A segurança do RSA depende (em alto nível) de um problema matemático unidirecional: multiplicar grandes primos é fácil, mas fatorar o número resultante em seus primos é extremamente difícil nos tamanhos usados na prática.
As chaves pública e privada são relacionadas matematicamente, mas a relação é projetada para que a chave pública não revele a privada de forma prática.
Eles resolvem objetivos de confiança diferentes:
Uma regra prática: criptografia protege segredos; assinaturas provam quem enviou algo e que não foi alterado.
Num fluxo simplificado de HTTPS/TLS:
O RSA pode ser usado para autenticação (assinaturas) e, historicamente, também foi usado para proteger o segredo inicial da sessão em algumas configurações.
Não. O cadeado indica principalmente que a conexão está criptografada e geralmente autenticada.
Ele não garante que:
Considere o HTTPS como uma camada necessária de segurança de transporte, não como um veredito completo de confiança.
Um certificado vincula uma chave pública a uma identidade (como um nome de domínio). Navegadores confiam nessa vinculação porque uma Autoridade Certificadora (CA) assina o certificado, e navegadores/OS vêm com uma lista de CAs confiáveis.
Se você está implantando serviços, planeje:
Atualizações assinadas permitem que seu dispositivo verifique duas coisas:
Isso defende contra ataques de “trocar o pacote” (mirrors comprometidos, redes sequestradas, páginas de download falsas). Para um aprofundamento, veja /blog/code-signing-basics.
Falhas reais tendem a ser operacionais, não a quebra da matemática do RSA:
Medidas práticas: proteja chaves privadas (preferencialmente em hardware), monitore emissões de certificados, acompanhe vencimentos e rode rotações de chaves quando necessário.