Leonard Adleman e RSA: Como a Internet Aprendeu a Confiar

Por que o RSA importa para a confiança cotidiana na internet

Quando as pessoas dizem que “confiam” em um site ou serviço online, normalmente querem três coisas práticas:

• Privacidade: estranhos não conseguem ler suas mensagens, senhas ou dados de pagamento enquanto viajam pela internet.
• Identidade: você está realmente falando com seu banco (ou aquela loja), e não com um impostor.
• Integridade: o que você recebe não foi silenciosamente alterado — seja uma página de login, uma solicitação de transferência ou uma atualização de software.

O RSA ficou famoso porque ajudou a tornar essas promessas possíveis em escala na internet.

Sistemas do dia a dia que o RSA ajudou a viabilizar

Você já sentiu o impacto do RSA mesmo que nunca tenha ouvido o nome. Ele está intimamente ligado a como:

• HTTPS protege muitas conexões entre seu navegador e um site (a ideia do “cadeado”).
• Bancos online deixaram de ser “talvez não faça isso na internet” para algo que milhões de pessoas usam.
• Softwares assinados e atualizações podem provar que vieram do editor real — e não foram adulterados no caminho até seu dispositivo.

O fio condutor é confiança sem precisar conhecer pessoalmente (ou combinar segredos com) cada servidor e fornecedor de software com quem você interage.

O que esperar deste guia

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”.

A ideia chave: duas chaves, dois papéis

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.

O papel de Leonard Adleman no avanço do RSA

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.

O que Adleman trouxe à equipe

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.

Onde o RSA se encaixa na história da criptografia

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.

O impacto duradouro

A influência do RSA vai além de um algoritmo. Ele tornou possíveis em escala duas necessidades essenciais da internet:

• Criptografia, para que os dados sejam protegidos em trânsito
• Assinaturas digitais, para que softwares e mensagens possam ser verificados como autênticos

Essas ideias sustentam como HTTPS, bancos online e atualizações assinadas se tornaram expectativas normais em vez de exceções raras.

O problema central que o RSA resolveu: comunicação segura sem segredos compartilhados

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.

Por que segredos compartilhados não escalam

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.

Dois estranhos, uma conversa segura

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.

Por que “apenas criptografar” não basta

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:

• Confidencialidade: estranhos não podem ler os dados.
• Autenticidade: você pode verificar com quem está falando (e que as mensagens não foram adulteradas).

O RSA ajudou a viabilizar ambas, lançando a base de como a confiança online funciona em escala.

Noções básicas de criptografia de chave pública (sem jargões)

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.

Chave pública vs. chave privada (em linguagem simples)

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.

Dois trabalhos principais: criptografia e assinaturas digitais

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:

• foi assinado pelo detentor da chave privada
• não foi alterado depois da assinatura

Por que funciona (sem equações)

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.

Como o RSA funciona em alto nível

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.

A ideia unidirecional (com uma porta traseira)

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.

Por que a fatoração importa

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 fluxo básico

1. Gerar chaves: seu dispositivo cria um par correspondente: uma chave pública e uma privada.
2. Publicar a chave pública: ela pode ser compartilhada abertamente — num site, num certificado ou num app.
3. Proteger a chave privada: ela deve permanecer secreta. Se vazar, a proteção se quebra.

Um detalhe prático que as pessoas esquecem

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.

Criptografia vs. assinaturas digitais: dois trabalhos diferentes

O RSA é famoso porque pode desempenhar duas funções relacionadas — mas muito diferentes —: criptografia e assinaturas digitais. Misturá‑las é fonte comum de confusão.

Três objetivos: confidencialidade, integridade, autenticidade

• Confidencialidade significa “só a pessoa pretendida pode ler”. Exemplo: você envia o número da sua conta para um site e não quer que mais ninguém veja.
• Integridade significa “não foi alterado no caminho”. Exemplo: um atacante não deveria conseguir mudar “transferir $50” para “transferir $5.000”.
• Autenticidade significa “veio de quem afirma ter vindo”. Exemplo: você quer saber se um e‑mail ou atualização realmente originou do seu banco ou fornecedor confiável.

Criptografia mira principalmente a confidencialidade. Assinaturas digitais almejam integridade + autenticidade.

RSA para criptografia: proteger uma mensagem (ou, mais comumente, uma chave)

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.

RSA para assinaturas: provar quem fez algo — e que não foi alterado

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:

• Isso veio realmente do detentor da chave privada? (autenticidade)
• Algo mudou desde a assinatura? (integridade)

Por que assinaturas importam na prática

Assinaturas digitais aparecem em momentos cotidianos de “aprovação”:

• Aprovação de transações: um banco pode assinar mensagens para que o app confie nas instruções recebidas.
• Downloads: um instalador assinado ajuda o computador a verificar se é do editor real.
• Atualizações: atualizações assinadas impedem que atacantes substituam por versões maliciosas, mesmo que consigam alterar o canal de entrega.

A criptografia protege segredos; as assinaturas protegem a confiança.

RSA e HTTPS: o que acontece quando você vê o cadeado

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.

Um handshake TLS simplificado (o que seu navegador realmente faz)

Quando você visita um site HTTPS, navegador e servidor realizam uma conversa de configuração chamada handshake TLS:

• O servidor envia um certificado. Ele inclui a chave pública do site e o nome de domínio que diz representar.
• Seu navegador verifica a identidade. Confirma que o certificado é válido para aquele domínio, não está expirado e foi assinado por uma Autoridade Certificadora (CA) confiável.
• Eles criam chaves de sessão. Uma vez satisfeito de que fala com a parte correta, os dois concordam em chaves simétricas temporárias para a sessão.

Onde o RSA entra

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.

Por que seus dados não são criptografados com RSA

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.

Como o HTTPS com RSA tornou o banco online prático

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.

O que os bancos precisavam que a web fizesse

Uma sessão bancária tem que proteger três coisas ao mesmo tempo:

• Logins: sua senha (e outros segredos) não podem ser expostos em trânsito.
• Transações: valores e contas de destino devem chegar exatamente como você enviou.
• Dados pessoais: detalhes de conta, endereços e mensagens não devem ser legíveis por quem vigia a rede.

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.

Como o HTTPS tornou suficientemente seguro confiar

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:

• Atacantes não conseguem ler seu tráfego (sem captura fácil de senhas por interceptação).
• Atacantes não conseguem alterar solicitações silenciosamente (sem transformar $50 em $5.000 em trânsito).

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.

Por que a identidade importa tanto quanto a criptografia

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.

Camadas extras (úteis, não substitutas)

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.

Distribuição segura de software: por que atualizações assinadas importam

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.

O ataque simples: trocar o pacote

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.

Assinatura de código: provar quem compilou (e que não foi alterado)

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.

O que isso significa para usuários do dia a dia

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.

Certificados e PKI: como chaves públicas se tornam confiáveis

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.

Autoridades Certificadoras: conectores de confiança, não mágica

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.

Expiração e revogação: o que acontece quando as coisas mudam

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.

Conselhos práticos de gerenciamento de chaves

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.

Limites, riscos e mal-entendidos comuns sobre o RSA

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.

Modos comuns de falha (o que realmente dá errado)

Alguns padrões reaparecem com frequência:

• Chaves fracas: uso de chaves RSA muito curtas ou configurações obsoletas reduz o custo do ataque.
• Armazenamento ruim de chaves: chaves privadas deixadas em servidores comprometidos, copiadas em backups ou checadas em repositórios podem ser roubadas sem quebrar criptografia.
• Phishing e comprometimento do endpoint: se um atacante engana uma pessoa para aprovar um login ou instala malware num dispositivo, o RSA não resolve; criptografia não corrige um endpoint hackeado.
• Emissão indevida de certificados: se uma CA emite o certificado errado, usuários podem ser redirecionados a um atacante ainda vendo HTTPS “válido”.

Por que comprimento da chave e aleatoriedade importam

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.

O RSA não é “lento demais”, mas é usado seletivamente

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.

O maior mal-entendido: “RSA sozinho me deixa seguro”

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.

RSA hoje: onde ainda se encaixa e o que costuma ser usado em seu lugar

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.

Por que sistemas seguem além do RSA

A criptografia evolui pelas mesmas razões que outras tecnologias de segurança:

• Velocidade e eficiência: operações RSA podem ser relativamente lentas e exigir chaves grandes. Métodos mais novos oferecem a mesma segurança com chaves menores e handshakes mais rápidos.
• Novas ameaças e margens de segurança: conforme a pesquisa avança, a comunidade reavalia o que é mais seguro e mais fácil de implementar corretamente.
• Designs melhores para uso moderno: a web precisa hoje de conexões rápidas, desempenho móvel e serviços em grande escala — empurrando padrões a favor de algoritmos que se encaixam nesses requisitos.

O que costuma ser usado junto ou em vez do RSA

Você verá alternativas comuns em TLS e aplicações modernas:

• ECDSA e Ed25519 para assinaturas digitais (provar que “este servidor/app é autêntico”). Costumam ser mais rápidas e usar chaves menores que RSA.
• ECDH para troca de chaves (acordar um segredo compartilhado para iniciar uma sessão criptografada). Isso explica porque muitas conexões HTTPS não dependem mais do RSA para a etapa principal de “trancar o segredo”.

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.

Então… o RSA está obsoleto?

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.