Este projeto implementa um canal de comunicação criptografado de ponta a ponta, desenvolvido para a disciplina de Criptografia (UFC Quixadá). O sistema utiliza criptografia híbrida para garantir a confidencialidade e integridade das mensagens.
O sistema foi estruturado de forma modular para separar a lógica de rede da lógica criptográfica.
- Broadcast & Discovery (UDP): O servidor envia um beacon (sinalizador) via UDP na porta 5001. Os clientes escutam essa porta para descobrir o IP do servidor automaticamente, eliminando a necessidade de configuração manual.
- Relay Server (TCP): O servidor funciona como um "espelho". Ele aceita duas conexões TCP na porta 5000 e repassa os bytes recebidos de um cliente diretamente para o outro, sem descriptografar o conteúdo (garantindo o segredo de ponta a ponta).
- Threads Independentes: O cliente utiliza threads para permitir que a interface de envio de mensagens e o recebimento de dados via rede ocorram simultaneamente, sem travamentos.
├── cliente_main.py # Interface do usuário e lógica de controle do cliente
├── run_server.py # Ponto de entrada do Servidor (Relay)
├── invasor.py # Ferramenta de interceptação (Sniffer)
├── requirements.txt # Dependências (cryptography, scapy)
└── src/
├── crypto/ # Núcleo de Criptografia Manual
│ ├── cbc.py # Implementação manual do modo Cipher Block Chaining
│ ├── ctr.py # Implementação manual do modo Counter Mode
│ ├── rsa_handshake.py# Protocolo RSA (Geração, Cifra e Troca)
│ └── utils.py # Primitivas AES-ECB, XOR e Padding PKCS#7
└── network/ # Infraestrutura de Redes
├── server.py # Lógica de sockets e repasse do servidor
└── protocolo.py # Constantes e definições do protocolo
As bibliotecas utilizadas foram selecionadas para garantir a manipulação de baixo nível de bytes e a execução da primitiva AES de forma eficiente.
| Biblioteca | Versão | Função no Projeto |
|---|---|---|
| cffi | 2.0.0 | Interface para chamadas de funções em C (requisito da cryptography). |
| cryptography | 46.0.3 | Fornece a primitiva AES-ECB e suporte a chaves RSA. |
| pycparser | 2.23 | Parser C utilizado internamente para extensões C do Python. |
| pycryptodome | 3.23.0 | Suporte adicional para funções criptográficas e manipulação de bytes. |
| scapy | 2.6.1 | Utilizada no invasor.py para sniffing e análise de pacotes de rede. |
Seguindo os requisitos mandatórios, não foram utilizadas funções prontas de bibliotecas para os modos de operação. Utilizamos apenas a primitiva de cifragem de bloco (AES-ECB) para processar blocos de 128 bits.
- Algoritmo Assimétrico: Utilização de RSA com chaves de 2048 bits.
- Protocolo de Troca: O Cliente A gera uma chave simétrica AES-128 aleatória e a cifra utilizando a chave pública do Cliente B. O segredo de sessão é estabelecido após o Cliente B decifrar o pacote com sua chave privada.
- Decisão de Padding Assimétrico: Foi utilizado o esquema RSA-OAEP (Optimal Asymmetric Encryption Padding). A escolha justifica-se pela sua resistência contra ataques de texto claro escolhido (Chosen Ciphertext Attacks) e por mitigar vulnerabilidades de Padding Oracle presentes em esquemas mais antigos como o PKCS#1 v1.5.
-
Lógica Manual: Implementação do encadeamento onde cada bloco de texto claro (
$P_i$ ) sofre uma operação XOR com o bloco cifrado anterior ($C_{i-1}$ ) antes da cifragem AES ($C_i = E_k(P_i \oplus C_{i-1})$). -
Gerenciamento de IV: O Vetor de Inicialização (IV) de 16 bytes é gerado aleatoriamente via
os.urandom(16)para cada mensagem. Ele é enviado como prefixo (primeiros 16 bytes) do pacote para que o receptor inicialize a decodificação do primeiro bloco. - Regra de Padding: Implementação manual do padrão PKCS#7, preenchendo o bloco até atingir o tamanho de 16 bytes.
- Lógica de Fluxo: O AES cifra um contador incremental (Nonce + Counter) para gerar um keystream. O texto cifrado é obtido através do XOR entre o texto claro e este fluxo ($C = P \oplus E_k(Counter)$).
- Gerenciamento de Nonce: Um Nonce de 8 bytes aleatório é gerado por mensagem e enviado no início de cada pacote. Ele é concatenado a um contador de 8 bytes que inicia em zero e incrementa a cada bloco de 16 bytes processado.
- Vantagem de Padding: Este modo opera como uma cifra de fluxo, portanto, o padding é desnecessário, uma vez que a operação XOR é aplicada apenas aos bytes existentes na mensagem original.
- Codificação Base64: Todos os dados cifrados são convertidos para Base64 antes do envio. Isso garante a integridade dos bytes na rede TCP, evitando que caracteres de controle ou bytes nulos corrompam o fluxo de dados.
- Sincronização de Modo: No início da conexão, o Cliente A envia um pacote de controle definindo o modo de operação (CBC ou CTR), garantindo que ambos os terminais instanciem o mesmo algoritmo para a sessão.
| Critério | Modo CBC | Modo CTR |
|---|---|---|
| Padding | Obrigatório (PKCS#7) | Não necessário |
| Eficiência | Pacotes múltiplos de 16 bytes | Pacotes de tamanho exato + Nonce |
| Resiliência | Propaga erros entre blocos | Erro afeta apenas o bit correspondente |
A implementação manual de ambos os modos permitiu uma análise profunda das exigências técnicas de cada um:
- Facilidade de Implementação: O modo CTR mostrou-se consideravelmente mais simples de codificar manualmente. Por transformar uma cifra de bloco em uma cifra de fluxo, ele permite que a lógica de cifragem e decifragem seja idêntica (XOR entre o texto e o keystream), o que reduz a complexidade do código e a probabilidade de bugs de implementação.
- Gestão de Blocos e Padding: O modo CBC exigiu maior rigor técnico devido à necessidade de preenchimento (Padding PKCS#7). A remoção precisa do padding na recepção é um ponto crítico: qualquer erro de um único byte no gerenciamento do IV ou no encadeamento dos blocos resulta em falha catastrófica de integridade na decodificação.
- Eficiência de Rede: O modo CTR é mais eficiente para mensagens curtas, pois não expande o dado original até o próximo múltiplo de 16 bytes, enviando apenas os bytes da mensagem mais os 8 bytes do Nonce.
Um dos objetivos centrais deste projeto é demonstrar a Confidencialidade. Abaixo, detalhamos a perspectiva do atacante durante a troca de mensagens.
Se um atacante executar o invasor.py (sniffer) na rede, ele conseguirá capturar todos os pacotes que passam pela porta 5000. No entanto, o que ele vê é limitado a:
- Endereços IP: Ele sabe quem está conversando com quem (Metadados).
- Volume de Dados: Ele sabe o tamanho das mensagens enviadas.
- Payload Cifrado: Ele vê uma sequência de caracteres em Base64 que, ao ser decodificada, resulta em bytes aleatórios (o Ciphertext).
- O Vetor de Inicialização (IV) ou Nonce: Estes valores viajam em texto claro no início do pacote, mas, sem a chave secreta, eles são inúteis para a decodificação.
A impossibilidade de leitura pelo invasor deve-se a dois fatores matemáticos:
- Segredo da Chave de Sessão (AES): A chave de 128 bits nunca é enviada de forma aberta. Ela é gerada por um cliente e "embrulhada" com a chave pública RSA do outro. Para o invasor descobrir essa chave, ele precisaria resolver o problema da fatoração de números inteiros grandes, o que é computacionalmente inviável com as tecnologias atuais.
- Difusão e Confusão: O algoritmo AES aplica múltiplas rodadas de operações matemáticas (SubBytes, ShiftRows, MixColumns). Isso garante que cada bit do texto claro dependa de vários bits da chave. Se o invasor tentar chutar uma letra da mensagem, ele falhará, pois não existe uma relação direta ou padrão visível entre o texto original e o cifrado.
Mesmo que você envie a mesma palavra "Bom dia" dez vezes seguidas, o invasor verá dez pacotes completamente diferentes:
- No modo CBC: O IV (Vetor de Inicialização) muda a cada mensagem, alterando o resultado do XOR do primeiro bloco.
- No modo CTR: O Nonce/Contador garante que o keystream seja único para cada envio.
Isso impede o Ataque de Replay ou a análise estatística, onde o invasor poderia tentar adivinhar palavras comuns baseando-se na repetição de padrões.
Siga os passos abaixo na ordem exata para garantir o funcionamento correto do ecossistema (Ambiente, Servidor, Invasor e Clientes).
É altamente recomendável o uso de um ambiente virtual para isolar as dependências e evitar conflitos:
No Linux / macOS:
- Criar o ambiente:
python3 -m venv venv - Ativar o ambiente:
source venv/bin/activate - Instalar dependências:
pip install -r requirements.txt
No Windows:
- Criar o ambiente:
python -m venv venv - Ativar o ambiente:
.\venv\Scripts\activate - Instalar dependências:
pip install -r requirements.txt
Para uma demonstração completa, siga esta sequência de terminais:
1º Terminal: Servidor (Relay) Deve ser o primeiro a ser iniciado para aceitar as conexões TCP e emitir o sinalizador de rede.
- Comando:
python3 run_server.py(Linux) oupython run_server.py(Windows)
2º Terminal: Invasor (Sniffer) - Opcional Inicie o invasor antes dos clientes para capturar o tráfego desde o início. Nota: No Windows, o Scapy pode exigir a instalação do Npcap; no Linux, exige privilégios de superusuário.
- Comando (Linux):
sudo ./venv/bin/python3 invasor.py - Comando (Windows):
python invasor.py(Executar terminal como Administrador)
3º e 4º Terminais: Clientes A e B
Abra dois terminais distintos, ative a venv em ambos e execute:
- Comando:
python3 cliente_main.py(Linux) oupython cliente_main.py(Windows)
Fluxo de Operação:
- No Cliente A: O sistema solicitará a escolha do modo (1 para CBC ou 2 para CTR).
- No Cliente B: O sistema aguardará a escolha do Cliente A e realizará o Handshake RSA automaticamente.
- Com o canal seguro ativo, as mensagens digitadas serão cifradas, codificadas em Base64 e enviadas via servidor de relay.
Abaixo estão as capturas de tela que demonstram o sistema em execução, desde a descoberta do servidor até a interceptação maliciosa falha.
Demonstração do servidor enviando o Beacon UDP e os clientes estabelecendo a chave de sessão segura.
Exemplo de troca de mensagens utilizando os diferentes modos de operação selecionados em tempo real.

Prova de que o atacante, ao interceptar os pacotes na porta 5000, visualiza apenas dados cifrados e o preenchimento (padding) no modo CBC.
- Tailan de Souza: Cliente-Servidor, Modo CTR, Integração e documentação.
- JV: Handshake RSA, Modo CBC e Utilitários.
- UFC Quixadá - 2025







