5. Algoritmos de criptografia. 

O quadro a seguir, mostra uma análise comparativa dos principais algorítmos: 

Algoritmos

 Tamanho de Bloco

 Tamanho de Chave

 Modo de Operações

DES

 Trabalha com bloco de 64 bits, dividindo-o em duas partes de 32bits cada.

 Inicialmente a chave de 64 bits sofre uma divisão, onde os bits múltiplos de 8 são desprezados reduzindo-a a 56bits. Em seguida, a chave é quebrada em duas partes de 28 bits.

 Possui quatro formas de operação: Eletronic Code Book (ECB) e Cipher Block Channing (CBC) considerados métodos de blocagem, e Cipher Feedback (CFB) e Output Feedback (OFB) que são do tipo Stream – cadeia contínua.

Triple DES

 Bloco de 64 bits

 Tamanho de chave para Triple DES com 2 chaves é 112 bits, para o que trabalha com 3 chaves é de 168 bits.

 Utiliza os mesmos modos de operação do algoritmo DES.

RC4

  

 Possui tamanho de chave variável.

 Seu modo de operação é semelhante ao  OFB – Output Feedback.

RSA

 Os blocos são cadeias binárias que representam um número inteiro menor que n, onde, tanto o emissor quanto o receptor devem o conhecer n.

 O RSA Laboratories recomenda que o tamanho de chave para proteção de dados de usuários limitados deve ser de 768 bits; para dados secretos e autoridades certificadoras um mínimo de 1024 bits é recomendado [RSASecurity].

 

 

 

Criptografia XOR

 

O que é e como funciona a criptografia XOR ?

XOR (eXtended OR) ou OU exclusivo, é um operador binário que compara dois bits, e então retorna 1 se os dois bits forem diferentes, ou 0 se eles forem iguais.

Exemplo:

A

B

A XOR B

0

0

0

1

0

1

0

1

1

1

1

0

 

Mas como isso é usado na criptografia ?

Isso é bem simples, sabemos que cada caractere (cada byte) tem seu valor binário na tabela ASCII, então vamos considerar que o byte A é o byte que será criptografado, que B é a chave, e que C (A XOR B) é o byte A criptografado pela chave B

Vamos assumir que A seja igual a '7' (decimal 55 e binário 00110111)
e que B seja igual a 'J' (decimal 74 e binário 01001010)
e então C (A XOR B) será igual a:
A 00110111
B 01001010
-----------------
C 01111101

O valor decimal de C seria, portanto, 125 (isto é conseguido tranformando o valor binário em decimal), que representa o caractere '{'

portanto:
A XOR B == C
Isto é: MENSAGEM XOR CHAVE == MENSAGEM CRIPTOGRAFADA
Em Decimal: 55 XOR 74 == 125
Em Caractere: '7' XOR 'J' == '{'
Em Binário:
00110111 XOR 01001010 = 01111101

Para criptografar uma string por uma chave de 8 bits (1 byte), XORariamos todos os caracteres da string A, pela chave B, obtendo com isso, C. Por exemplo:

STRING_A = "OLA!"
B = 'C' (Obs: o caractere 'C' tem o decimal 67 e o binário 01000011)

Agora fazemos:
STRING_C[0] = STRING_A[0] XOR B (Obs: a string começa do 0)
aqui, STRING_A[0] equivale ao primeiro caractere da string (isto é, o 'O', que tem o decimal igual a 79 e o binário igual a 01001111)
como eu disse mais acima, o caractere 'C' tem o binário igual a 01000011, então:
Sendo STRING_A[0] (caractere 'O') == 01001111
e a chave B (caractere 'C') sendo == 01000011
e então, STRING_C[0] (que é o primeiro byte da mensagem criptografada) será igual a:
A 01001111
B 01000011
-----------------
C 00001100

Esse byte retornado do A XOR B (00001100) tem o valor decimal 12, e não tem um valor que pode ser impresso, mas não nos importemos com isso agora, e vamos XORar o resto da string:

STRING_A[1] (caractere 'L', decimal == 76 e binário == 01001100)
A 01001100
B 01000011
-----------------
C 00001111
portanto, STRING_C[1] é igual à: decimal: 15 e binário 00001111, esse caractere também não pode ser impresso.

STRING_A[2] (caractere 'A', decimal == 65 e binário == 01000001)
A 01000001
B 01000011
-----------------
C 00000010
portanto, STRING_C[2] é igual à: decimal: 2 e binário 00000010, esse caractere também não pode ser impresso.

STRING_A[3] (caractere '!', decimal == 33 e binário == 00100001)
A 00100001
B 01000011
-----------------
C 01100010
portanto, STRING_C[3] é igual à: decimal: 98 e binário 01100010, esse é o valor do caractere 'b'.

Agora, a encriptação está completa, e temos STRING_A criptograda em STRING_C, pela chave B. Simples, não ? hmm realmente, mais ainda falta algo ...

... como faço para decriptar essa mensagem ???

Para decriptar é tão simples quando encriptar !
Para isso, basta fazer o processo inverso da encriptação, assim:

(Obs: Apenas para relembrar, A = Mensagem a ser encriptada, B = Chave, C = Mensagem encriptada)

Para encriptar:
C = A XOR B

Para decriptar:
A = B XOR C

Um exemplo:

Encriptando:
A = 00110000 (Decimal 48)
B = 11000100 (Decimal 146)
Logo,
C = 11110100 (Decimal 244) (A encriptada pela chave B)

Decriptando:
B = 11000100 (Decimal 146)
C = 11110100 (Decimal 244)
E o que temos ?
A = 00110000 (Decimal 48) ! (C decriptada pela chave B)

Últimas considerações e exemplo prático:

Se você quiser fazer uma chave com mais de 8 bits, você pode fazer assim:
digamos que a chave tem 16 bits (2 bytes) e que a mensagem a ser encriptada tenha 9 bytes
A = "COMO VAI?"
B = "OI"
faça:
A[0] XOR B[0]
A[1] XOR B[1]
A[2] XOR B[0]
A[3] XOR B[1]
A[4] XOR B[0]
A[5] XOR B[1]
A[6] XOR B[0]
A[7] XOR B[1]
A[8] XOR B[0]

O operador XOR na linguagem C é ^ e ^=

RC6

O National Institute of Standards and Technology (NIST) tem trabalhado com a indústria e a comunidade criptográfica para desenvolver o Advanced Encription Standard (AES), ou o padrão de criptografia avançado. O objetivo total é desenvolver um padrão federal para processo de informação (PLF) que especifique algoritmo(s) de criptografia capaz de proteger a informação sensível do governo bem no século seguinte. O algoritmo(s) esperado será usado pelos Governo Norte Americano e, em uma base voluntária, pelo setor confidencial.

Em 2 de janeiro de 1997 foi feito um atendimento formal para os algoritmos de criptografia participarem da seleção do novo padrão americano. Em 20 de janeiro de 1998 foram anunciados os 15 algoritmos selecionados através da comunidade de criptografia global. Em 15 de abril de 1999, numa nova seleção, dos 15, permaneceram apenas 5: Projeto Mars, o Projeto Rijndael, o Projeto Serpent, o Projeto Twofish e o Projeto RC6, o qual estudaremos um pouco mais nesse trabalho.

O RC6 foi projetado por Ron Rivest na colaboração com laboratórios de RSA e é uma melhoria evolucionária sobre RC5, e como RC5, faz o uso essencial de rotações dados-dependentes. A análise adiantada sugere que RC6 ofereça ambos: boa segurança e bom desempenho.

A filosofia do RC5 é explorar as operações (tais como rotações) que são executadas eficientemente em processadores modernos. RC6 continua esta tendência e faz exame da vantagem do fato que a multiplicação do inteiro 32-bits está executada agora eficientemente na maioria de processadores. A multiplicação desse inteiro é uma primitiva muito eficaz da " difusão ", e é usada no RC6 para computar quantidades de rotação, de modo que as quantidades da rotação sejam dependentes de todos os bits de um outro registo, melhor que apenas os bits low-order (como em RC5).

Os trabalhos RC6 com quatro registradores w-bits A, B, C, D que contêm o textoplano inicial da entrada tão bem quanto a mensagem cifrada da saída no fim da criptografia. O primeiro byte do textoplano ou da mensagem cifrada é colocado no byte menos significante de A; o último byte do textoplano ou da mensagem cifrada é colocado no byte mais-significante de D. Nós usamos (A, B, C, D) = (B, C, D, A) para significar a atribuição paralela dos valores da direita aos registradores da esquerda.


 

O modelo acima apresenta como o texto plano é criptografado antes de ser transmitido para o destino.

 

SECURANÇA

 Don Coppersmith observa, entretanto, que à custa da memória considerável e da pre-computação off-line pode montar um ataque do meio (meet-in-the-middle) para recuperar a key array S[ 0....43 ]. Isto requereria 2704 esforços computacionais on-line e assim que o esforço do trabalho requerido para recuperar a key array expandida pode melhor ser estimado por min {28b, por 2704 } operações.

Nós podemos sumarizar nossas reivindicações na segurança de RC6 como segue:

O melhor ataque em RC6 aparenta ser uma busca exaustiva pela chave de criptografia fornecida pelo usuário as exigências de dados para montar ataques mais sofisticados em RC6 tal como a cryptanalise diferencial e linear, excedem os dados disponíveis

Não existe nenhum exemplo conhecido de o que pode denominadar chaves “fracas”.