Criptografia assimétrica com o RSA

Devido a dificuldade de troca de chaves, os algoritmos assimétricos são o principal motor de comunicações cifradas sobre SSL, como o HTTPS. De fácil compreensão, o RSA é um interessante método matemático que permite a cifra assimétrica baseado em números primos. E você pode brincar de RSA com a sua calculadora bc de linha de comando.

[ Hits: 179.424 ]

Por: Elgio Schlemer em 05/08/2009 | Blog: http://gravatai.ulbra.tche.br/~elgio


Não frite seu processador



O RSA é brilhante, mas seu uso foi considerado como não prático durante muitos anos. Seu uso de forma segura requer a escolha de números p e q muito grandes, fazendo com que o d, principalmente, seja igualmente de muitos bits.

Considere o uso do e em um espaço de 17 bits, como o usado oficialmente pelo RSA: e = 65537. Ao usar este valor como e, a fórmula de euclides calculará d = 65, pois:

$ echo "(65 * 65537) % 352" | bc
1
$

Agora, com esta pequena variação, cifrar algo, como por exemplo, a letra 'z', cujo valor decimal é 122, significa elevar na potência 65 e extrair o módulo 391:

$ echo "(122 ^ 65) % 391" | bc
309
$

Muito embora a parte 12265 resulte em um número com 136 dígitos, o cálculo em um processador normal pode ser realizado em milisegundos.

Já a decifragem deve ser feita com o 65537 sendo que decifrar significa elevar a este número:

30965537 mod 391

No meu processador foram necessários dois segundos para completar a operação, sendo que a operação de exponenciação gerou um número com mais de 160 mil dígitos!

E se está pegando muito leve, pois uma chave real, verdadeira, usada pelo RSA deve ser de, pelo menos, 1024 bits. Não tente fazer isto em sua calculadora bc, mas ai está um exemplo real de uma chave oficial do RSA gerada através do openssl. E pasmem: é apenas uma "chavesinha fraquinha" de 256 bits:

p = 334534313289524152888573174586934053249
q = 276472048961512623704414856403001554787
n = 92489387043087324784734008299373122418017833935069759252445487098782848852963
e = 65537
d = 36109769233737818015273648021057724389187611534029825167304543901118715705601

Alguém ai tem coragem de cifrar um simples caractere com esta chave? É só elevar a 65537. Moleza. E para decifrar, basta elevar ao simpático número 36109769233737818015273648021057724389187611534029825167304543901118715705601!

Este foi um dos impasses a que chegaram os pesquisadores do GCHQ e que os fizeram achar o algoritmo impraticável devido ao fato de que os cálculos exigiam muito processamento, muito além do hardware existente na época. Ainda hoje isto é uma completa utopia se não fosse possível simplificar a operação através de reduções matemáticas.

Não vou descrever como é possível reduzir drasticamente o esforço matemático desta operação, mas eu tenho uma implementação deste princípio em Cálculo de X na potência Y modulo N. Para usar este programa, digite VOL como matricula, já que o script PHP destina-se ao uso de alunos enquanto solucionando problemas de aula. Faça uma teste: veja quanto tempo o teu processador levará para calcular 1234765531 mod 107803 = 39618 (fazendo um echo "12347 ^ 65531 % 107803" | bc). Dependendo do seu processador, isto poderá demorar uns 10 segundos. Depois veja quanto tempo o script PHP, que usa a redução matemática, precisou.

Sem este atalho matemático o RSA seria inviável, pois os meros 256 bits anteriores ainda são insuficientes para garantir segurança. Com os atalhos matemáticos, o RSA pode ser usado, mas ainda assim ele é considerado um algoritmo que consome uma monstruosidade de processamento. Por isto seu emprego deve ser muito, mas muito restrito.

No protocolo SSL, por exemplo, ele é usado apenas o tempo necessário para que ambas as partes estabeleçam uma chave de sessão. Todo o tráfego de dados são cifrados usando um simétrico, mas rápido, e esta chave que ambos estabeleceram. Economia de processamento. Em assinaturas digitais, o mesmo princípio, pois se usa o RSA para assinar o hash da mensagem, que sempre tem o mesmo tamanho (128 bits no caso do MD5).

Página anterior     Próxima página

Páginas do artigo
   1. Introdução
   2. A teoria dos algoritmos assimétricos
   4. RSA passo a passo
   5. Não frite seu processador
   6. Quebrando o RSA: um desafio para você valendo um livro
   7. Conclusão
Outros artigos deste autor

Introdução a criptografia

Armazenamento de senhas no Linux

Autenticação por desafio e resposta no SSH

Estrutura do IPTables 2: a tabela nat

Fundamentos da criptografia assimétrica

Leitura recomendada

Tomcat + SSL: HOW-TO

Jails em SSH: Montando sistema de Shell Seguro

Enviando e recebendo e-mails criptografados através do Thunderbird

Segurança Física (Parte 1)

Instalando o Nagios via APT ou YUM

  
Comentários
[1] Comentário enviado por cesar em 05/08/2009 - 14:34h

Nota 10!

parabéns elgio!

[]'s

[2] Comentário enviado por elgio em 05/08/2009 - 14:53h


VALENDO!

Valores de N publicados!
http://www.vivaolinux.com.br/topico/Seguranca-Da-Informacao/Desafio-1-RSA

[3] Comentário enviado por cesar em 05/08/2009 - 15:17h

@elgio

Fiquei interessado neste "teorema de Euclides e atalhos matemáticos para cálculo de módulo" tem como você me enviar este material por e-mail? não sei se pode mandar por causa do desafio, mas quando concluir o desafio tú me manda?
meu e-mail é [email protected]

[]'s

[4] Comentário enviado por elgio em 05/08/2009 - 15:33h

O teorema de euclides é uma pequena variação da fórmula para cálculo do máximo divisor comum. Está publicado no meu site e o link é fornecido no artigo.

Quanto ao atalho matemático, claro. Mas depois. com o tempo. Também teria as explicações dos 3 testes de primaridade. não sou matemático, mas sou curioso. Corri muito atras de alguns conceitos para poder entender e até mesmo ACREDITAR no RSA :-D

Estou escrevendo um NOVO artigo sobre linguagens que irá ajudar MUITO a quebrar o N. Mas este eu vou segurar para publicar depois.

[5] Comentário enviado por fernandoborges em 06/08/2009 - 13:13h

Prof. Elgio, parabéns pelo rigor com que tratou o assunto. Mesmo sendo formado em Matemática, ainda me faltavam alguns conceitos que relacionassem Teoria dos Numeros e Criptografia Assimétrica. Comecei uma Pós nesse ramo em 2007, mas infelizmente tive que trancar. Seu artigo me remeteu ao OpenVPN, que aliás, é uma das minha ferramentas em meu trabalho atual. O Sr poderia fazer uma análise da segurança implementada no OpenVPN com certificados X509 à luz de seu conhecimento sobre criptografia?

[6] Comentário enviado por elgio em 06/08/2009 - 13:57h

Fernando:

Não importa qual programa, nenhum deles usa algoritmos Assimétricos para cifrar!

Os assimétricos, como o RSA ou o DSA são computacionalmente inviáveis, devido ao esforço matemático exigido. Um processador não daria conta de cifrar um download de um CD Iso, por exemplo.

TODOS ELES usam algoritmos SIMÉTRICOS, por serem bons e rápidos.

Olhando o man do openvpn vi que ele prefere usar o algoritmo simétrico blowfish em modo CBC (Cipher-Block Chaining, ou seja, como um algoritmo de bloco encadeando-os para evitar repetição).

Mas como toda boa ferramenta profissional, o OpenVPN suporta diversos algoritmos (execute openvpn --show-ciphers para ter uma listagem do seu).

Assim, a segurança dos dados em tráfego dependem do algoritmo e do tamanho da chave. O menor deles, ma minha versão de openvpn, é o DES com 64 bits que já está fraquinho. Usar ele pode significar estar fragilizado.

O Blowfish padrão usa 128 bits que está MUITO, mas MUITO BOM (o pessoal acha que é pouco já que o RSA deve ser de, pelo menos, 1024. Mas são princípios matemáticos distintos: http://www.vivaolinux.com.br/artigo/Introducao-a-criptografia cap 6)

Bom, mas onde entra o certificado e a criptografia assimétrica?

Quando cliente e servidor negociam, há uma troca de certificados. Um certificado tem muitas informações, incluindo a chave pública, podento estar assinado por uma certificadora.

Um certificado usa diversos algoritmos:
- RSA ou algum outro assimétrico: esta chave deve ser de pelo menos 1024 bits. Menos que isto é perigoso

- HASH: Pra as assinaturas digitais. Não convém mais usar o MD5 por conta das colisões descobertas. O bam bam bam de agora é o SHA1

Ocorre que no início cliente e servidor CRIAM uma chave de sessão de 128 bits para ser usado pelo simétrico (no caso o blowfish). Podem fazer isto usando o protocolo Diffie-Hellman. Esta negociação irá precisar de algumas mensagens, TODAS CIFRADAS PELO RSA (e gastando CPU!).

Mas são só estas poucas, pois assim que uma chave de sessão é trocada, abandonam o lentérrimo RSA e usam o "rapidésimo" simétrico (blowfish no exemplo).

Então, caro amigo, o openssl é sim EXTREMAMENTE SEGURO se observadas algumas coisas:

a) que se use algoritmos bons. O padrão que vem nele está "da hora"
b) que se usem certificados bons, sem MD5 de preferência
c) que se use uma chave forte RSA, se for o caso, de, pelo menos, 1024 bits


[7] Comentário enviado por elgio em 07/08/2009 - 10:01h

VALENDO!

Valores de N publicados!
http://www.vivaolinux.com.br/topico/Seguranca-Da-Informacao/Desafio-1-RSA

[8] Comentário enviado por fernandoborges em 08/08/2009 - 16:34h

Prof. Elgio,
Quero agradecê-lo pela rápida abordagem sobre o OpenVPN. Muito esclarecedor pra mim. Será de grande valia para que eu possa avaliar melhor a segurança dos dados que trafegam na minha VPN.
Cordiais saudações,
Fernando.

[9] Comentário enviado por marcelogpl em 09/08/2009 - 01:32h

Parabéns Professor!

Realmente um artigo muito interessante e claro nos conceitos utilizados, vai ajudar muito em projetos onde um dos focos é a segurança.

Obrigado

[10] Comentário enviado por elgio em 12/08/2009 - 16:52h

Novo desafio postado.

ESTE VALE UM LIVRO!
http://www.vivaolinux.com.br/topico/Seguranca-Da-Informacao/Desafio-2-RSA

[11] Comentário enviado por elgio em 13/08/2009 - 10:08h

Ontem pela manhã removi o link do artigo que remetia para o cálculo do D em C. Ele não funcionava para todos os casos. Agora eu REFIZ o código e voltei a citar o código em C no artigo. Esta versão, em C, FUNCIONA e corretamente calcula qualquer valor de D, mas só se ele estiver dentro da capacidade da ULA. Necessário para GANHAR O LIVRO do desafio.

Ah, mas com este código não dá para quebrar todos os D?

Ora, modifique ele: http://www.vivaolinux.com.br/artigo/Programacao-com-numeros-inteiros-gigantes/

[12] Comentário enviado por Lisandro em 10/06/2010 - 07:04h

Ótimo Artigo. Parabéns!

[13] Comentário enviado por rafatmb em 23/11/2010 - 17:23h

Excelente documentação sobre o assunto. Informações fundamentais para todos os administradores de rede linux.

um bom material de apoio em: http://cseweb.ucsd.edu/~mihir/papers/oae.pdf

Acho importante sabermos a história das coisas, e de onde vieram as soluções que hoje fazem parte do dia a dia. Muitas vezes, usamos tanto, que nem atribuimos a devida importante para as ferramentas, e deixamos também de reconhecer aqueles que passaram tanto tempo estudando e desenvolvendo a tecnologia.

Abraço a todos!

Rafael Marangoni
LPIC/1/2/3 - Expertise em Servidor Linux
http://www.brlink.com.br



[14] Comentário enviado por uberalles em 01/12/2010 - 01:28h

Grande e excelentíssimo Professor. Que pena que só encontrei este artigo agora.. há dois meses atrás, por volta de outubro, tive que fazer um programa em C, com API MySQL para tratar senhas e tals e acabei usando a função ENCODE() e DECODE() do próprio MySQL, sendo que queria ter feito em C. talvez eu reveja e refaça uma nova versão, mas a que tenho hoje está muito boa.

Um abraço e muito obrigado.
.

[15] Comentário enviado por DavidsonDFGL em 26/07/2012 - 22:13h

Poxa, de longe o melhor artigo de RSA que já li na internet, tanto que até tive vontade de implementar algo simples em C, mas me veio uns problemas:

o programa gerou aleatoriamente
p = 5
q = 11
e = 7
o n 55
o qq 40
e o d deu 23
acontece que quando cifro o número 10 por ex, o resultado é 10 também, e decifrado vira 18.
Isso seria uma infeliz coincidência, ou tem algo de muito errado com estes valores? confesso que já vi e revi estes valores e aparentemente estão certos, :(

[16] Comentário enviado por sk4d1nh4 em 26/11/2012 - 17:02h


[17] Comentário enviado por DavidsonDFGL em 26/07/2012 - 22:13h:

Poxa, de longe o melhor artigo de RSA que já li na internet, tanto que até tive vontade de implementar algo simples em C, mas me veio uns problemas:

o programa gerou aleatoriamente
p = 5
q = 11
e = 7
o n 55
o qq 40
e o d deu 23
acontece que quando cifro o número 10 por ex, o resultado é 10 também, e decifrado vira 18.
Isso seria uma infeliz coincidência, ou tem algo de muito errado com estes valores? confesso que já vi e revi estes valores e aparentemente estão certos, :(


Caro DavidsonDFGL,

acredito que tenha alguma coisa errada no seu "C". Decifrando o 10 com esses números da 10 mesmo. Faça o teste. echo (10^23)%55 | bc

[17] Comentário enviado por fabinhotfj em 21/02/2013 - 20:55h

Parabéns pelo seu artigo


[18] Comentário enviado por dougaslinux em 01/10/2013 - 00:19h

Olá, Ótimo poste!

Se alguem poder me confimar alguns sistemas que utilizam a criptografia RSA , ficarei muito grato!

[19] Comentário enviado por reinaldobatista em 15/07/2014 - 13:16h

Excelente! Parabéns! Bravo!


Contribuir com comentário