Ataque de Texto Claro Conhecido: Como Derivar uma Chave XOR Repetida a Partir de um Crib
O desafio
Um cliente VPN guarda seu bloco de provisionamento em hexadecimal e faz XOR com uma frase secreta curta e repetida que não está anotada em lugar nenhum. Você não consegue decifrar o bloco enquanto não souber essa frase, então precisa deduzi-la em vez de procurá-la. O que você tem é uma pista de texto conhecido: o bloco é JSON, e a documentação do fornecedor mostra que toda carga de provisionamento começa exatamente com os doze caracteres {\"vpn_user\": ou seja, você já conhece os doze primeiros bytes do texto claro. XOR é o seu próprio inverso e esse é todo o truque. Decodifique o hexadecimal, faça XOR dos bytes contra o texto que você já conhece, e leia o que aparece no começo do resultado. Envie a frase secreta, não o bloco decifrado.
O que você vai aprender
- Usar a propriedade de autoinversão do XOR para recuperar uma chave em vez de um texto claro
- Aplicar um crib de texto claro conhecido a um texto cifrado com XOR de chave repetida
- Determinar o tamanho da chave a partir do período da repetição recuperada
- Reconhecer o limite onde o crib termina e a saída volta a ser ruído
- Verificar uma chave recuperada decifrando a mensagem completa
Habilidades testadas
Pré-requisitos
- Entender que o XOR é o seu próprio inverso
- Familiaridade com codificação hexadecimal como camada de transporte
Como funciona
Todo outro exercício de XOR entrega a chave e pede para você aplicá-la. Este retém a chave, o que muda a questão de decodificação para criptoanálise. O caminho de entrada é a identidade mais útil da criptografia simétrica: o XOR desfaz a si mesmo, então, se ciphertext = plaintext XOR key, temos que ciphertext XOR plaintext = key.
Esse rearranjo é o que torna o texto claro conhecido tão perigoso. Você não precisa da mensagem inteira, apenas de um trecho dela. Formatos estruturados entregam esse trecho de graça: payloads JSON, cabeçalhos de arquivo, banners de protocolo e textos padrão de e-mail sempre começam de forma previsível. Aqui, a documentação do fornecedor mostra que todo bloco de provisionamento começa com {\"vpn_user\":, que são doze bytes conhecidos.
Decodifique o hexadecimal para bytes brutos, depois faça XOR contra esses doze caracteres. Na região conhecida, o texto claro se cancela e a chave fica exposta. A saída mostra Gl4c13rGl4c1: a chave Gl4c13r, seguida pelos cinco primeiros caracteres dela de novo. Essa repetição não é ruído, é a medição. O padrão recomeça depois de sete caracteres, então a chave tem sete bytes, e o crib ser mais longo que a chave é exatamente o motivo pelo qual a chave inteira pode ser recuperada, e não apenas parte dela.
Depois do décimo segundo byte, a saída degrada em ruído, porque a bancada continua ciclando seu crib contra texto cifrado real cujo texto claro você não conhecia. Essa transição marca o limite do que você realmente sabia. Trocar a chave para Gl4c13r decifra o bloco inteiro, o que é o passo de confirmação.
Erros comuns
- Tentar quebrar a chave por força bruta. Uma frase secreta alfanumérica de sete caracteres é um espaço grande demais para adivinhar, e o crib torna a adivinhação desnecessária.
- Fazer XOR do texto hexadecimal em vez dos bytes. From Hex precisa vir primeiro, senão você está fazendo XOR dos caracteres ASCII dos dígitos hexadecimais.
- Ler além do crib. Só os primeiros doze caracteres da saída do XOR com o crib têm significado; tudo depois é ruído por construção.
- Enviar a repetição inteira.
Gl4c13rGl4c1é a chave repetida. A chave em si é a unidade de sete caracteresGl4c13r. - Enviar o bloco decifrado. A pergunta pede a frase secreta, não o JSON que ela desbloqueia.
- Recorrer ao Vigenère. Ele só transforma letras e deixaria a pontuação e os dígitos do JSON intactos.
Como se proteger
XOR de chave repetida é ofuscação, não criptografia, e um texto claro conhecido o desmonta em um único passo. Qualquer coisa previsível no formato da sua mensagem é um oráculo de recuperação de chave.
- Nunca proteja segredos com XOR contra uma frase secreta estática. Use criptografia autenticada, como AES-GCM ou ChaCha20-Poly1305.
- Derive chaves com um KDF adequado e nunca incorpore uma frase secreta no software cliente, onde ela é recuperável por definição.
- Lembre-se de que uma chave mais curta que qualquer prefixo previsível é totalmente recuperável, então o tamanho da chave e a estrutura da mensagem são problemas relacionados.
- No caso específico de provisionamento, emita credenciais de curta duração a partir de um servidor, em vez de enviar uma semente de longa duração dentro de um bloco do lado do cliente.
- Trate uma semente de OTP como equivalente ao próprio segundo fator. Recuperar esse bloco derrota o MFA que ela deveria sustentar.