Concryptor

Um motor de criptografia AEAD multithread construído em Rust. Criptografa e descriptografa arquivos com throughput de gigabytes por segundo usando um pipeline io_uring com triplo buffer, processamento paralelo de chunks via Rayon e cifras otimizadas em assembly via ring.

⚠️ AVISO: SOFTWARE EXPERIMENTAL ⚠️

Este projeto é extremamente novo e atualmente NÃO é recomendado para uso em produção ou missões críticas. Embora os primitivos criptográficos (AES-256-GCM, ChaCha20-Poly1305 via ring) e o design do formato sejam sólidos, a base de código não passou por auditorias formais de segurança ou testes extensivos no mundo real. Use por sua conta e risco. Para proteger dados sensíveis, considere usar ferramentas testadas em campo como GnuPG, age ou OpenSSL até que este projeto amadureça.

Funcionalidades

• Suporte a duas cifras: AES-256-GCM (AES-NI por hardware) e ChaCha20-Poly1305 via ring (otimizada em assembly)
• Criptografia paralela: Processamento multithread de chunks baseado em Rayon em todos os núcleos da CPU
• Pipeline io_uring com triplo buffer: Sobreposição de E/S do kernel e criptografia da CPU usando três pools de buffers rotativos — enquanto as gravações de um lote estão em andamento, o próximo lote está sendo criptografado pelo Rayon, e as leituras do terceiro lote estão em andamento. Sem overhead de syscall por chunk, sem limitações de mmap (sem SIGBUS, sem exaustão de espaço de endereçamento virtual)
• Derivação de chave Argon2id: Alongamento de senha padrão da indústria (padrão 256 MiB de memória, 3 iterações, configurável via --memory)
• Parâmetros KDF autodescritivos: Custo de memória, iterações e paralelismo são armazenados no cabeçalho do arquivo criptografado, de modo que a descriptografia usa exatamente os parâmetros escolhidos no momento da criptografia. Arquivos legados (sentinelas todos zeros) são tratados de forma transparente com os antigos padrões de 64 MiB
• Nonces indexados por chunk: Derivação de nonce estilo TLS 1.3 (XOR) evita ataques de reordenação de chunks
• AAD autenticado pelo cabeçalho: O cabeçalho completo de 4 KiB alinhado é incluído no AAD de cada chunk, autenticando todos os campos do cabeçalho (núcleo, parâmetros KDF e bytes reservados) e prevenindo ataques de truncamento, manipulação de campos do cabeçalho e smuggling de bytes reservados
• Chunk final estilo STREAM: Uma flag de chunk final no AAD impede ataques de truncamento e anexação (inspirado na construção STREAM)
• Aleatoriedade nova por arquivo: Sal criptograficamente aleatório de 16 bytes e nonce base de 12 bytes são gerados para cada criptografia, armazenados no cabeçalho
• Criptografia in-place: seal_in_place_separate_tag / open_in_place via ring minimiza alocações no loop principal
• Zeroizaçao de senha: Chaves e senhas são limpas da memória com segurança após o uso
• O_DIRECT + formato alinhado a setor: Cabeçalho e slots de chunk alinhados a 4 KiB permitem E/S O_DIRECT, ignorando o cache de página do kernel para leituras/gravações em velocidade DMA em NVMe. Os pools de buffers usam std::alloc com alinhamento de 4096 bytes
• Criptografia de diretórios: Criptografe diretórios inteiros como um único arquivo criptografado. A empacotamento baseado em tar preserva nomes de arquivos, permissões, timestamps e estrutura de diretórios dentro do texto cifrado. A extração valida contra ataques de path traversal e escape de symlink
• Formato de arquivo autodescritivo: O cabeçalho armazena cifra, tamanho do chunk, tamanho original do arquivo, sal, nonce base e parâmetros KDF do Argon2id

Desempenho

Benchmark feito com cargo bench (Criterion, 10 amostras por medição). A derivação de chave está excluída — os números refletem apenas o throughput puro de criptografia.

Hardware:

• CPU: AMD Ryzen 5 5600X (6c/12t @ 3.7 GHz base)
• RAM: 2x 8 GiB DDR4-2666 (dual channel, 16 GiB total)
• OS: Linux

Nota sobre E/S: O Criterion grava arquivos temporários em /tmp, que neste sistema é tmpfs (backed por RAM). Com O_DIRECT, o kernel não pode usar DMA assíncrono real em tmpfs, portanto esses números refletem throughput de cifra + overhead de io_uring sem o benefício de bypass DMA. Em uma unidade NVMe Gen4 real, O_DIRECT elimina o double-buffering do cache de página e permite DMA diretamente nos pools de buffers alinhados, o que deve resultar em throughput significativamente maior.

Tamanho do Arquivo	Criptografia AES-256-GCM	Criptografia ChaCha20	Descriptografia AES-256-GCM	Descriptografia ChaCha20
64 KiB	244 MiB/s	233 MiB/s	233 MiB/s	234 MiB/s
1 MiB	1.08 GiB/s	882 MiB/s	1010 MiB/s	876 MiB/s
16 MiB	1.10 GiB/s	923 MiB/s	1.06 GiB/s	988 MiB/s
64 MiB	984 MiB/s	935 MiB/s	988 MiB/s	973 MiB/s
256 MiB	1.00 GiB/s	1015 MiB/s	1.01 GiB/s	1.02 GiB/s

Varredura de tamanho de chunk (AES-256-GCM, arquivo de 64 MiB):

Tamanho do Chunk	Throughput
64 KiB	1.01 GiB/s
256 KiB	1.05 GiB/s
1 MiB	1.07 GiB/s
4 MiB	988 MiB/s
8 MiB	988 MiB/s
16 MiB	1.00 GiB/s

Características de desempenho

O motor usa ring (AES-NI / NEON / ARMv8-CE otimizado em assembly) para operações de cifra e um pipeline io_uring com triplo buffer para E/S. Três pools de buffers pré-alocados giram pelo pipeline: enquanto as gravações do pool A estão sendo concluídas no kernel, o pool B está sendo criptografado pelo Rayon na CPU, e as leituras do pool C estão sendo submetidas ao kernel. Isso sobrepõe a latência de E/S com a computação criptográfica.

Por que AES-256-GCM é mais rápido que ChaCha20-Poly1305 em arquivos pequenos: O backend AES-GCM do ring explora instruções de hardware AES-NI + CLMUL disponíveis em x86-64, dando-lhe uma vantagem de hardware sobre o ChaCha20 (que é uma cifra de software). Em tamanhos maiores, ambas as cifras convergem para ~1.0 GiB/s, indicando que o gargalo muda de throughput de cifra para overhead de submissão de E/S.

Por que o throughput máximo está em 1-16 MiB, não em 256 MiB: Arquivos pequenos (1-16 MiB) têm poucos chunks, então o paralelismo do Rayon é eficiente e o conjunto de trabalho cabe no cache. Em 64-256 MiB, o pipeline io_uring está totalmente ativo (três lotes em voo), mas o overhead de submissão por SQE e conclusão por CQE escala com o número de chunks. O design de triplo buffer garante sobreposição de E/S e criptografia, ocultando parcialmente esse custo.

Por que ~1.0 GiB/s e não 10+ GiB/s: AES-NI moderno pode atingir 2-4 GiB/s por núcleo. Com 12 threads, o throughput bruto de cifra poderia exceder 10 GiB/s. Três fatores explicam a diferença: