Quando se trata de escolher uma cifra de encriptação simétrica em 2026, AES-256-GCM e ChaCha20-Poly1305 dominam as discussões técnicas em todo o mundo. Ambas oferecem segurança de 256 bits, autenticação integrada e resistência a ataques conhecidos, mas o desempenho, o comportamento em hardware e os casos de uso ideal divergem de forma significativa. Em servidores modernos com aceleração por hardware, o AES-256-GCM supera o ChaCha20-Poly1305 até 3 vezes. Em dispositivos IoT sem instruções AES, a equação inverte-se completamente. Este artigo analisa dados reais de benchmarks, opiniões de especialistas e cenários práticos para que a decisão seja baseada em factos, não em mitos.
O que é AES-256-GCM
O Advanced Encryption Standard (AES) foi padronizado pelo NIST em 2001 através da publicação FIPS 197, substituindo o DES e o Triple DES como padrão de encriptação simétrica para uso governamental e comercial. A variante com chave de 256 bits é a mais robusta da família, utilizando 14 rondas de substituição, permutação e mistura de colunas para transformar blocos de 128 bits de dados em texto cifrado aparentemente aleatório.
O modo GCM (Galois/Counter Mode) transforma o AES num AEAD (Authenticated Encryption with Associated Data), ou seja, a cifra não só encripta os dados como também garante a sua integridade através de uma tag de autenticação de 128 bits. Isto elimina a necessidade de combinar o AES com um HMAC separado, reduzindo a complexidade do código e o risco de erros de implementação.
A grande vantagem do AES-256-GCM em 2026 é a ubiquidade das instruções AES-NI nos processadores modernos. Desde Intel Sandy Bridge (2011) e AMD Bulldozer (2012), praticamente todos os processadores para desktop, servidor e a maioria dos SoCs ARM de gama média-alta incluem instruções dedicadas que aceleram as operações AES por hardware. Numa pipeline AES-NI, o processador executa uma ronda completa de AES num único ciclo de relógio, em vez dos dezenas de ciclos necessários numa implementação puramente em software.
O AES-256-GCM é obrigatório no TLS 1.3 como uma das duas cipher suites padrão, aparece no HTTPS, no SSH, na encriptação de disco (FileVault, BitLocker, LUKS), em bases de dados e em sistemas de ficheiros encriptados. Segundo o NIST, mantém uma margem de segurança de 128 bits contra ataques quânticos através do algoritmo de Grover, tornando-o adequado para dados com classificação TOP SECRET.
Um ponto frequentemente esquecido: o AES-256-GCM é a única opção certificada pelo FIPS 140-3 entre os dois algoritmos. Para organizações em Portugal que operam em sectores regulados como banca, saúde ou serviços de administração pública, esta certificação pode ser um requisito obrigatório ao abrigo do Regulamento DORA ou da directiva NIS2, com coimas que chegam a 10 milhões de euros por incumprimento.
O que é ChaCha20-Poly1305
O ChaCha20 foi criado por Daniel J. Bernstein, um dos criptógrafos mais influentes das últimas décadas, como uma variante do Salsa20 optimizada para velocidade e resistência a ataques de temporização. O algoritmo baseia-se em operações aritméticas simples, conhecidas como ARX (adição, rotação de bits e XOR), que correm em tempo constante em qualquer processador, sem necessidade de tabelas de lookup ou instruções especializadas.
O Poly1305 é um autenticador de mensagens criado também por Bernstein, que complementa o ChaCha20 para formar o AEAD ChaCha20-Poly1305, formalizado na RFC 8439 da IETF. A combinação usa uma chave de 256 bits, um nonce de 96 bits e produz uma tag de autenticação de 128 bits, exatamente como o AES-256-GCM em termos de parâmetros AEAD.
O XChaCha20-Poly1305 é uma extensão com nonce alargado de 192 bits, em vez de 96 bits, o que reduz drasticamente o risco de colisão de nonces em sistemas distribuídos ou aplicações que geram nonces aleatoriamente. O NordPass e outros gestores de palavras-passe modernos adoptaram o XChaCha20 precisamente por este motivo: com um espaço de nonce 2^96 vezes maior, a probabilidade de reutilização acidental de nonces aproxima-se do zero mesmo em infraestruturas de grande escala.
A adopção do ChaCha20-Poly1305 por gigantes tecnológicos como o Google e a Cloudflare foi motivada pela sua excelente performance em dispositivos móveis Android sem AES-NI e pela sua resistência natural a ataques de temporização em implementações de software, tal como a Cloudflare documentou no seu blog oficial. A equipa da Cloudflare foi pioneira na adopção em larga escala, publicando dados que mostravam performance 3 vezes superior ao RC4 em dispositivos Android sem AES-NI.
O protocolo WireGuard usa exclusivamente ChaCha20-Poly1305, sem negociação de cipher suite. Os criadores do WireGuard optaram por esta abordagem deliberada: eliminar a negociação remove superfície de ataque (downgrade attacks) e o ChaCha20 funciona bem em qualquer hardware onde o WireGuard seja instalado. O protocolo Double Ratchet do Signal usa AES-256-CBC com HMAC-SHA256, demonstrando que mesmo aplicações focadas em privacidade adoptam AES em contextos específicos.
Tabela de Especificações Técnicas: AES-256-GCM vs ChaCha20-Poly1305
| Característica | AES-256-GCM | ChaCha20-Poly1305 |
|---|---|---|
| Tamanho da chave | 256 bits | 256 bits |
| Tamanho do bloco / stream | Bloco 128 bits | Stream (sem bloco fixo) |
| Nonce / IV | 96 bits (padrão GCM) | 96 bits (RFC 8439) / 192 bits (XChaCha20) |
| Tag de autenticação | 128 bits (GHASH) | 128 bits (Poly1305) |
| Número de rondas | 14 rondas | 20 rondas |
| Tipo de cifra | Bloco (modo CTR + GHASH) | Stream (ARX: add-rotate-xor) |
| Padronização | NIST FIPS 197 (2001) | RFC 8439 IETF (2018) |
| Aceleração hardware | AES-NI em Intel/AMD/ARM | Software puro (sem instruções dedicadas) |
| Resistência a timing attacks | Depende da implementação | Nativa (operações em tempo constante) |
| Segurança pós-quântica | 128 bits (Grover, chave 256 bits) | 128 bits (Grover, chave 256 bits) |
| Licença | Domínio público / NIST | Domínio público |
| FIPS 140-3 certificado | Sim (via OpenSSL, BoringSSL) | Não |
| Usado em TLS 1.3 | Sim (cipher suite padrão) | Sim (cipher suite padrão) |
| Risco de nonce reuse | Catastrófico (expõe chave GHASH) | Grave (expõe relações entre plaintexts) |
Benchmarks de Desempenho: 3 Fontes Independentes
Os benchmarks de 2025 mostram uma imagem clara: em hardware com aceleração AES, o AES-256-GCM vence com margem significativa. Em hardware sem essa aceleração, o ChaCha20-Poly1305 mantém-se competitivo ou superior. Os números que se seguem provêm de três fontes independentes publicadas em 2025.
Fonte 1: Benchmark de Ash Vardanian (AWS Graviton 2, 2025)
Ash Vardanian publicou em 2025 um benchmark multi-CPU que compara AES-256-GCM e ChaCha20-Poly1305 em payloads de 100 bytes a 1 KB. Os resultados num AWS Graviton 2 (ARM com aceleração AES activa) mostram uma vantagem consistente do AES acelerado:
| Operação | ChaCha20-Poly1305 | AES-256-GCM | Vantagem AES |
|---|---|---|---|
| Encriptação (100B a 1KB) | 168 a 503 MB/s | 292 a 1.065 MB/s | +91% a +118% |
| Desencriptação (100B a 1KB) | 197 a 491 MB/s | 412 a 1.104 MB/s | +109% a +125% |
A conclusão de Vardanian é directa: “Em 2025, o AES-256-GCM supera o ChaCha20-Poly1305 até 3 vezes em todos os CPUs modernos com aceleração por hardware.” O investigador acrescenta que o argumento “os dispositivos móveis precisam de ChaCha20”, que circulou desde 2015, já não se aplica a chips modernos. O texto refere ainda o artigo académico “Too Much Crypto” de 2019, que sugere que ambos os algoritmos são sobre-provisionados em rondas: o AES-256 usa 14 rondas mas precisaria apenas de cerca de 11; o ChaCha20 usa 20 rondas mas cerca de 8 seriam suficientes para segurança prática.
Fonte 2: Benchmark Vitalvas no Apple M3 Pro (blocos de 1 MB, 2025)
O benchmark Vitalvas para blocos de 1 MB no Apple M3 Pro, com a Apple Cryptographic Engine activa, mostra a dimensão real da diferença entre hardware acelerado e software puro:
| Algoritmo | Throughput | Condição |
|---|---|---|
| AES-256-GCM | 6,4 GB/s | Com hardware acceleration |
| XChaCha20-Poly1305 | 4,2 GB/s | Software puro |
| AES-256-GCM | 1,8 GB/s | Sem hardware acceleration |
O dado crítico é o AES sem hardware: 1,8 GB/s contra 4,2 GB/s do XChaCha20. Sem aceleração, o ChaCha20 é 133% mais rápido. Com a Apple Cryptographic Engine, o AES-256-GCM atinge 6,4 GB/s, superando o XChaCha20 por 52%. Este benchmark ilustra porque é que a escolha depende do hardware e não de uma preferência abstracta.
Fonte 3: RustCrypto AEAD em Intel Xeon Platinum 8272CL
O benchmark do repositório RustCrypto AEAD, executado num Intel Xeon Platinum 8272CL com suporte AVX512, regista:
- AES-256-GCM: 820 a 837 MB/s
- ChaCha20-Poly1305: 404 a 423 MB/s
Neste ambiente de servidor de produção típico, o AES-256-GCM é aproximadamente 2 vezes mais rápido. Para servidores que processam milhares de pedidos HTTPS por segundo, esta diferença traduz-se em poupança real de CPU e menor custo de infraestrutura cloud. Com CPUs que suportam as extensões vaes e vpclmulqdq (disponíveis em Xeon Ice Lake e posteriores), o ganho é ainda maior.
Aceleração por Hardware: AES-NI e os Dispositivos sem Suporte
A instrução AES-NI (AES New Instructions) foi introduzida pela Intel em 2010 e representa a diferença fundamental entre os dois algoritmos no mundo real. Com AES-NI, o processador pode executar uma ronda completa de encriptação AES num único ciclo de relógio, transformando uma operação que levaria 100 a 300 MB/s em software numa operação que atinge 4 a 8 GB/s.
Processadores com AES-NI ou equivalente:
- Intel: Sandy Bridge (2011) e posteriores, incluindo toda a linha Core i3/i5/i7/i9 moderna e Xeon
- AMD: Bulldozer (2012) e posteriores, incluindo Ryzen 3/5/7/9 e EPYC
- ARM: Cortex-A57 e posteriores, Apple A7 e superiores, Qualcomm Snapdragon 801 e superiores
- Apple Silicon: M1, M2, M3, M4 (Apple Cryptographic Engine dedicada)
Dispositivos sem aceleração AES adequada:
- CPUs x86 anteriores a 2011 (Intel Atom N450, alguns Core 2 Duo)
- ARM Cortex-A5, A7, A8 (smartphones de 2010 a 2013)
- Microcontroladores IoT: ESP8266, alguns modelos STM32, PIC32 sem extensões criptográficas
- RISC-V embedidos sem extensões Zkne/Zknd
- Raspberry Pi Zero e Pi 1 (ARM11, sem instruções AES)
Para este segundo grupo de hardware, o ChaCha20-Poly1305 é a escolha técnica correcta. Um estudo de 2025 indica que o XChaCha20 pode atingir 1,5 GB/s em CPUs modernos sem aceleração AES, e consome aproximadamente 25% menos energia do que o AES implementado em software em dispositivos móveis de gama baixa. Em IoT alimentado a bateria, esta diferença energética pode duplicar a vida útil da bateria em aplicações com encriptação intensiva.
Para verificar em Node.js se o AES-NI está a ser utilizado via OpenSSL:
// Verificar suporte e benchmark básico de AES-256-GCM em Node.js
const { createCipheriv, randomBytes } = require('crypto');
const key = randomBytes(32);
const iv = randomBytes(12);
const plaintext = Buffer.alloc(1024 * 1024); // 1 MB
const start = process.hrtime.bigint();
const cipher = createCipheriv('aes-256-gcm', key, iv);
const encrypted = Buffer.concat([cipher.update(plaintext), cipher.final()]);
const end = process.hrtime.bigint();
const ms = Number(end - start) / 1e6;
const throughputMBps = 1024 / ms * 1000;
console.log(`AES-256-GCM: ${throughputMBps.toFixed(0)} MB/s`);
// Com AES-NI activo: esperar 1000-4000+ MB/s
// Sem AES-NI: esperar 100-300 MB/sAnálise de Segurança: Pontos Fortes e Vulnerabilidades
Do ponto de vista da segurança teórica, ambos os algoritmos são considerados seguros contra todos os ataques conhecidos em 2026. A diferença não está na resistência criptográfica abstracta, mas no comportamento face a erros de implementação e nos vetores de ataque práticos específicos de cada algoritmo.
Risco de Reutilização de Nonce
O risco mais crítico para ambos os AEADs é a reutilização de nonce com a mesma chave. Se o mesmo nonce for utilizado duas vezes, as consequências são graves em ambos os casos, mas de formas distintas:
- AES-256-GCM com nonce reutilizado: expõe a chave de autenticação GHASH, comprometendo completamente a integridade de todas as mensagens cifradas com essa chave. Um atacante consegue forjar mensagens autenticadas sem conhecer a chave AES. É considerado o cenário de falha mais catastrófico entre os AEADs modernos, documentado em ataques reais a implementações TLS defeituosas.
- ChaCha20-Poly1305 com nonce reutilizado: o XOR do keystream entre dois textos cifrados fica exposto, podendo revelar relações entre as mensagens originais. Igualmente grave para a confidencialidade, mas com um vector de ataque diferente do AES-GCM.
O XChaCha20-Poly1305 mitiga este risco de forma elegante: com um nonce de 192 bits, é seguro gerar nonces aleatoriamente usando um CSPRNG mesmo para volumes muito elevados de mensagens. Com nonces de 96 bits (AES-GCM e ChaCha20 padrão), a probabilidade de colisão aleatória começa a ser relevante após aproximadamente 2^32 mensagens com a mesma chave, o que corresponde a cerca de 4 mil milhões de mensagens.
Ataques de Temporização (Timing Attacks)
O ChaCha20 foi desenhado explicitamente para execução em tempo constante. As operações ARX (add-rotate-xor) que compõem o algoritmo correm em exactamente o mesmo número de ciclos independentemente dos valores dos dados, tornando-o naturalmente resistente a ataques de cache (cache-timing attacks) e ataques de temporização em implementações de software.
O AES em software pode vazar informação de temporização através de acessos à memória cache dependentes dos dados (S-box lookups). Esta vulnerabilidade foi explorada em ataques como o Bernstein cache-timing attack de 2005 e em ataques FLUSH+RELOAD em ambientes de virtualização partilhada. A solução prática é usar AES-NI: as instruções de hardware executam em tempo constante e eliminam completamente este vector de ataque. Em implementações de software puro, o ChaCha20 oferece uma postura de segurança superior sem configuração adicional.
Protocolos e Software que Usam Cada Cifra em 2026
A escolha de cifra não é apenas uma decisão de implementação própria. O protocolo ou framework em que se trabalha frequentemente dita qual cifra está disponível, ou qual é preferida por padrão.
| Protocolo / Software | Cifra utilizada | Notas |
|---|---|---|
| TLS 1.3 | Ambas disponíveis | AES-256-GCM e ChaCha20-Poly1305 são as duas cipher suites obrigatórias no RFC 8446 |
| WireGuard | ChaCha20-Poly1305 exclusivo | Sem negociação de cipher suite por design; WireGuard-AES em investigação activa |
| Signal (Double Ratchet) | AES-256-CBC + HMAC-SHA256 | Usa AES-CBC com HMAC no Double Ratchet; ChaCha20 em camadas de transporte |
| QUIC / HTTP/3 | Ambas (via TLS 1.3) | Cliente e servidor negoceiam a cipher suite mais eficiente para o hardware |
| SSH (OpenSSH 9.x) | AES-256-GCM preferido | [email protected] disponível; AES-GCM favorecido em servidores modernos |
| BitLocker (Windows) | AES-256-XTS | Modo XTS para encriptação de disco; sem modo GCM |
| FileVault (macOS) | AES-256-XTS | Apple Cryptographic Engine acelera por hardware |
| NordPass | XChaCha20-Poly1305 | Adoptou XChaCha20 pelo espaço de nonce alargado (192 bits) |
| OpenSSL 3.x | AES-256-GCM padrão | Prefere AES-GCM quando AES-NI presente; ChaCha20 como fallback |
| LUKS2 (Linux disk) | AES-256-XTS | ChaCha20 não disponível nas cipher suites LUKS por padrão |
O TLS 1.3, que protege a esmagadora maioria do tráfego HTTPS em 2026, implementa ambas as cifras como cipher suites obrigatórias. O RFC 8446 exige suporte para TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 e TLS_CHACHA20_POLY1305_SHA256. Na prática, stacks como OpenSSL e BoringSSL priorizam AES-256-GCM em hardware com AES-NI e recorrem ao ChaCha20-Poly1305 quando a aceleração não está disponível, exactamente como previsto pelos autores do protocolo.
5 Casos de Uso Reais: Qual Usar em Cada Cenário
Caso 1: API HTTPS em Servidor Cloud com Intel ou AMD
Uma API REST em Node.js a correr num servidor AWS EC2 c6i.xlarge (Intel Ice Lake com AES-NI e AVX-512) serve 10.000 pedidos por segundo, cada um com payload cifrado de 4 KB. Neste cenário, o AES-256-GCM é a escolha correcta. O throughput de 820 a 837 MB/s num Xeon Platinum e o suporte nativo via OpenSSL com AES-NI activo traduzem-se em latência de encriptação abaixo de 1 microssegundo por pedido. O ChaCha20 daria resultados funcionais mas com 50 a 60% menos throughput sem qualquer benefício de segurança adicional neste contexto.
Caso 2: Aplicação Móvel Android para Mercados com Hardware Heterogéneo
Uma aplicação de mensagens para Android a distribuir no Brasil, Índia e Sudeste Asiático tem como target dispositivos de 2017 a 2020 com Snapdragon 430 ou MediaTek MT6753, que carecem de aceleração AES robusta. O ChaCha20-Poly1305 é mandatório neste caso. A diferença de consumo energético de 25% é crítica em dispositivos com bateria de 3.000 mAh, e a performance em software puro é consistente independentemente do modelo de dispositivo.
Caso 3: Gestor de Palavras-Passe com Sincronização Multiplataforma
Um gestor de palavras-passe que sincroniza cofres encriptados entre dispositivos heterogéneos (Mac M3, iPhone 16, Android antigo, Raspberry Pi) beneficia do XChaCha20-Poly1305. O nonce alargado de 192 bits elimina o risco de colisão mesmo com geração aleatória de nonces. O comportamento de software puro é consistente em todos os dispositivos. O NordPass adoptou exactamente esta abordagem por estas razões, tornando o XChaCha20 o padrão para gestores de palavras-passe modernos.
Caso 4: Base de Dados com Encriptação de Campos PII em Contexto Regulado
Um sistema que encripta campos PII (nome, NIF, IBAN) numa base de dados PostgreSQL com aplicação a correr em servidores dedicados com Intel Xeon deve usar AES-256-GCM. A conformidade com FIPS 140-3, necessária para contratos governamentais e sectores regulados como banca e saúde em Portugal ao abrigo do DORA, exige AES. O ChaCha20-Poly1305 não está certificado FIPS, o que pode inviabilizar a aprovação de auditoria em contextos regulados.
Caso 5: Dispositivo IoT com Transmissão Cifrada em Bateria
Um sensor IoT baseado em ESP32 (Xtensa LX7 a 240 MHz) que transmite leituras cifradas a cada 30 segundos deve usar ChaCha20-Poly1305. O ESP32 tem aceleração AES por hardware, mas a biblioteca ChaCha20 em C puro ocupa menos memória flash e RAM, relevante em MCUs com 520 KB de SRAM. Para MCUs sem aceleração AES como o ESP8266 ou Raspberry Pi Zero W, o ChaCha20 não é apenas preferível, é praticamente a única escolha com performance aceitável.
Tabela de Preços e Custos de Implementação
Tanto o AES-256 como o ChaCha20 são algoritmos de domínio público sem licenciamento por utilização. Os custos reais surgem na implementação, conformidade e infraestrutura.
| Factor de Custo | AES-256-GCM | ChaCha20-Poly1305 |
|---|---|---|
| Licença do algoritmo | Gratuito (domínio público, NIST) | Gratuito (domínio público) |
| Certificação FIPS 140-3 | Incluída em OpenSSL 3.x, BoringSSL | Não certificado (custo adicional de compliance) |
| Custo de CPU (servidor com AES-NI) | Baixo (acelera por hardware, menos ciclos) | Médio (software puro, mais ciclos de CPU) |
| Custo de energia (IoT e mobile) | Mais elevado sem hw acceleration (+25%) | Baixo (eficiente em software, menos bateria) |
| Biblioteca em Node.js | Módulo crypto nativo (incluído) | @noble/ciphers ou libsodium-wrappers (gratuito) |
| Suporte em HSMs | Universal (todos os HSMs certificados) | Limitado (apenas HSMs recentes) |
| Custo de auditoria de segurança | Menor (mais familiar a auditores e reguladores) | Ligeiramente superior (menor familiaridade regulatória) |
Em Portugal, o Regulamento (UE) 2022/2554 (DORA) para o sector financeiro e a conformidade com a NIS2 (transposta pelo Decreto-Lei n.º 20/2025) privilegiam criptografia certificada. As coimas por incumprimento podem atingir 10 milhões de euros ou 2% da facturação global anual. Neste contexto, o custo de usar ChaCha20 em vez de AES em sistemas que requerem FIPS 140-3 pode ser muito superior ao custo de licenciamento.
Guia de Migração: AES-256-GCM e ChaCha20-Poly1305
A migração entre os dois AEADs é tecnicamente directa porque ambos têm a mesma interface: chave de 256 bits, nonce único, dados associados opcionais e tag de autenticação de 128 bits. O desafio está nos detalhes operacionais de segurança durante a transição.
Passo 1: Auditoria do código existente
# Procurar todas as referências ao algoritmo actual no código
grep -r "aes-256-gcm\|AES_256_GCM\|aes256gcm" --include="*.js" --include="*.ts" .
grep -r "chacha20\|ChaCha20\|xchacha" --include="*.js" --include="*.ts" .Passo 2: Migração de AES-256-GCM para ChaCha20-Poly1305 em Node.js
// ANTES: AES-256-GCM (módulo crypto nativo)
const { createCipheriv, createDecipheriv, randomBytes } = require('crypto');
function encryptAES(plaintext, key) {
const iv = randomBytes(12); // nonce de 96 bits
const cipher = createCipheriv('aes-256-gcm', key, iv);
const encrypted = Buffer.concat([cipher.update(plaintext, 'utf8'), cipher.final()]);
const tag = cipher.getAuthTag();
return { iv, encrypted, tag };
}
// DEPOIS: XChaCha20-Poly1305 com @noble/ciphers (nonce 192 bits)
// npm install @noble/ciphers
const { xchacha20poly1305 } = require('@noble/ciphers/chacha');
const { randomBytes } = require('crypto');
function encryptXChaCha(plaintext, key) {
const nonce = randomBytes(24); // nonce de 192 bits para XChaCha20
const stream = xchacha20poly1305(key, nonce);
const encrypted = stream.encrypt(Buffer.from(plaintext, 'utf8'));
// tag de 16 bytes incluída nos últimos bytes do encrypted
return { nonce, encrypted };
}
function decryptXChaCha(nonce, encrypted, key) {
const stream = xchacha20poly1305(key, nonce);
return Buffer.from(stream.decrypt(encrypted)).toString('utf8');
}Passo 3: Gestão segura de dados existentes durante a migração
- Adicionar um campo de versão de cifra ao envelope de encriptação (ex:
{"v":2,"alg":"xchacha20","nonce":"...","data":"..."}) para identificar qual algoritmo foi usado em cada registo - Manter ambas as implementações activas durante o período de transição (mínimo 30 dias de overlap)
- Nunca reutilizar nonces ao gerar novo material encriptado; cada mensagem precisa de um nonce único gerado com CSPRNG
- Re-encriptar dados sensíveis em background com o novo algoritmo, validando a desencriptação antes de apagar a versão antiga
Passo 4: Verificação de cipher suites no servidor TLS
# Verificar cipher suites TLS 1.3 disponíveis
openssl ciphers -v 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256'
# Testar handshake com ChaCha20-Poly1305 explicitamente
openssl s_client -connect servidor.exemplo.pt:443 \
-ciphersuites TLS_CHACHA20_POLY1305_SHA256 -tls1_3
# Ver qual cipher suite foi negociada
openssl s_client -connect servidor.exemplo.pt:443 2>&1 | grep "Cipher :"Opiniões de Especialistas
Ash Vardanian, investigador de performance e autor de benchmarks criptográficos amplamente citados em 2025, defende que “o AES-256-GCM supera o ChaCha20-Poly1305 até 3 vezes em todos os CPUs modernos com aceleração por hardware” e que a recomendação “os dispositivos móveis precisam de ChaCha20” é uma simplificação que não reflecte o hardware actual. A sua análise multi-CPU é um dos benchmarks mais citados em discussões técnicas de 2025.
Daniel J. Bernstein, criador do ChaCha20 e referência mundial em criptografia aplicada, projectou o algoritmo com uma filosofia explícita: maximizar a segurança em implementações de software sem dependência de hardware especializado. O seu trabalho documentado em cr.yp.to continua relevante em 2026, especialmente para sistemas embebidos e dispositivos com limitações de energia onde o AES-NI não está disponível.
A equipa de segurança da Cloudflare foi pioneira na adopção de ChaCha20-Poly1305 em larga escala no TLS. A sua análise publicada no blog oficial da Cloudflare foi determinante para a inclusão do ChaCha20-Poly1305 como cipher suite obrigatória no TLS 1.3. Os dados da Cloudflare mostravam ganhos de performance de 3 vezes face ao RC4 em dispositivos Android sem AES-NI, justificando a adopção em 2016.
ThePrimeagen, engenheiro de software e criador de conteúdo técnico com mais de 400 mil seguidores no YouTube, partilhou em streams a sua perspectiva prática: para aplicações Rust ou Go a correr em servidores cloud modernos, “usa o que a tua TLS stack escolhe automaticamente; ela sabe o que o hardware suporta”. A recomendação reflecte a realidade de que para a maioria dos programadores, a escolha é feita pela biblioteca TLS com base no hardware disponível.
A comunidade de criptografia aplicada, incluindo discussões no r/crypto e em fóruns técnicos como o Hacker News, converge numa perspectiva partilhada: “A diferença de segurança entre os dois algoritmos é desprezível na prática. A diferença de performance depende inteiramente do hardware. Escolhe ChaCha20 se tens dúvidas sobre o suporte AES-NI do dispositivo alvo; usa AES-256-GCM se o hardware é controlado e moderno.”
Criptografia Pós-Quântica: Impacto em AES-256 e ChaCha20
A questão pós-quântica para cifras simétricas é frequentemente mal compreendida. O algoritmo quântico de Grover reduz efectivamente o espaço de busca para chaves simétricas de N bits para N/2 bits. As implicações práticas para os dois algoritmos são as seguintes:
- AES-128: segurança efectiva reduzida de 128 bits para 64 bits sob Grover, considerada insuficiente no cenário de computadores quânticos de grande escala
- AES-256: segurança efectiva reduzida de 256 bits para 128 bits, considerada adequada e robusta para os próximos 30 ou mais anos
- ChaCha20-Poly1305 com chave de 256 bits: mesma redução para 128 bits, igualmente seguro no cenário pós-quântico
O NIST confirma na sua publicação FIPS 197 actualizada que o AES-256 é considerado seguro no cenário pós-quântico. Do ponto de vista quântico, ambos os algoritmos com chave de 256 bits mantêm uma margem de segurança equivalente e adequada.
A ameaça quântica real e urgente em 2026 não está nas cifras simétricas: está na criptografia assimétrica. RSA, ECDSA e ECDH ficam comprometidos pelo algoritmo de Shor com computadores quânticos suficientemente grandes. É por isso que o NIST padronizou em 2024 o ML-KEM (CRYSTALS-Kyber) para encapsulamento de chaves e o ML-DSA (CRYSTALS-Dilithium) para assinaturas digitais, para substituir RSA e ECC na troca de chaves e assinaturas. AES-256 e ChaCha20-Poly1305 podem continuar a ser usados como cifras simétricas em arquitecturas pós-quânticas sem qualquer alteração.
Para aprofundar este tema, consulte o artigo sobre criptografia pós-quântica e os padrões NIST de 2026 publicado neste site.
Prós e Contras: Análise Comparativa
AES-256-GCM: Prós e Contras
| Prós | Contras |
|---|---|
| Até 3x mais rápido com AES-NI activo | 100 a 300 MB/s em software sem AES-NI |
| Certificação FIPS 140-3 (obrigatória em sectores regulados) | Vulnerável a timing attacks em implementações de software puro |
| Suporte universal em HSMs certificados | Nonce misuse catastrófico: expõe chave GHASH |
| Padrão em TLS 1.3, SSH, BitLocker, LUKS, FileVault | Nonce de 96 bits: risco de colisão após ~4 mil milhões de mensagens por chave |
| Módulo crypto nativo no Node.js | Não recomendado sem hardware acelerado em IoT de baixo custo |
| 128 bits de segurança pós-quântica (chave 256 bits) | Implementação em modo GCM mais complexa que stream cipher |
ChaCha20-Poly1305: Prós e Contras
| Prós | Contras |
|---|---|
| Performance consistente em qualquer hardware | Mais lento que AES-256-GCM em servidores com AES-NI (2 a 3x) |
| Resistência nativa a timing attacks (operações ARX constantes) | Sem certificação FIPS 140-3 |
| XChaCha20: nonce de 192 bits elimina risco de colisão aleatória | Suporte limitado em HSMs antigos |
| Ideal para IoT, mobile e embedded sem AES-NI | Requer biblioteca externa no Node.js |
| Design simples e auditável (sem tabelas de lookup) | Não disponível por padrão em BitLocker, FileVault, LUKS |
| WireGuard usa exclusivamente ChaCha20 por design | Menor familiaridade em auditorias de conformidade regulatória |
Recomendações por Caso de Uso: Quando Escolher Cada Cifra
Com base nos benchmarks, análise de segurança e requisitos de conformidade documentados, as recomendações práticas para 2026 são:
- Servidores cloud modernos com Intel ou AMD (AWS, Azure, GCP, OVHcloud): use AES-256-GCM. AES-NI está sempre presente nestes ambientes e o ganho de até 3x de throughput é real, documentado e consistente nos benchmarks de 2025.
- Aplicações móveis Android para hardware heterogéneo ou IoT sem AES-NI: use ChaCha20-Poly1305. Performance consistente sem dependência de instruções de hardware que podem não estar presentes. Economia de energia de 25% em dispositivos com bateria.
- Sectores regulados em Portugal (banca, saúde, governo) com FIPS 140-3 obrigatório: use AES-256-GCM. A certificação FIPS é frequentemente obrigatória. O DORA, a NIS2 e contratos públicos em Portugal privilegiam ou exigem criptografia certificada.
- Gestores de palavras-passe, cofres de dados e sistemas com geração aleatória de nonces em volume: use XChaCha20-Poly1305. O nonce alargado de 192 bits elimina o risco de colisão, simplifica a gestão de nonces e reduz o risco de erros de implementação.
- VPNs baseadas em WireGuard: o ChaCha20-Poly1305 já é a única opção disponível no protocolo WireGuard. Para OpenVPN ou IKEv2/IPsec em servidores modernos, o AES-256-GCM é preferível pelo throughput superior.
Veredicto Final: AES-256-GCM vs ChaCha20-Poly1305 em 2026
A resposta baseada em dados de 2025 a 2026 é esta: não existe um vencedor universal. A escolha correcta depende do hardware onde o código corre, dos requisitos de conformidade regulatória e do perfil de risco específico de cada implementação.
Use AES-256-GCM quando: o hardware garante AES-NI (qualquer servidor cloud moderno, qualquer desktop Intel ou AMD desde 2012, iPhones desde o A7, Macs Apple Silicon); quando a conformidade com FIPS 140-3 é um requisito; quando o throughput máximo em hardware controlado é prioritário; e quando a integração com sistemas como BitLocker, LUKS ou HSMs é necessária.
Use ChaCha20-Poly1305 ou XChaCha20 quando: o hardware alvo é heterogéneo ou inclui dispositivos sem AES-NI; quando a aplicação é para IoT, embedded ou dispositivos móveis de gama baixa; quando a resistência nativa a timing attacks em software é prioritária; e quando a gestão de nonces em volume torna o espaço alargado do XChaCha20 uma vantagem operacional.
O TLS 1.3 já toma esta decisão automaticamente, priorizando AES-256-GCM quando AES-NI está disponível e recorrendo ao ChaCha20-Poly1305 caso contrário. Para a maioria das aplicações web, simplesmente deixar o TLS 1.3 negociar a cipher suite óptima é a estratégia correcta e não requer configuração manual.
Do ponto de vista da segurança criptográfica pura em 2026, ambos são equivalentes: sem ataques práticos conhecidos, margem pós-quântica de 128 bits com chave de 256 bits, e o principal risco em ambos é a reutilização de nonces, não o algoritmo em si. A decisão é operacional e de infraestrutura, não criptográfica.
Cobertura Relacionada
Para aprofundar os temas abordados neste artigo, consulte os seguintes recursos:
- AES-256 em Node.js: implementação passo a passo com exemplos práticos
- Encriptação Simétrica vs Assimétrica: diferença de 1000x na velocidade
- Criptografia Pós-Quântica: 50% da Web Protegida com ML-KEM em 2026
- mTLS em Node.js: TLS 1.3 em 12 Passos com certificados mútuos
- WireGuard vs OpenVPN: 3 a 4 vezes mais rápido com ChaCha20
- Hashing e Criptografia Explicados: guia completo para programadores
FAQ: AES-256-GCM vs ChaCha20-Poly1305
O AES-256-GCM é mais seguro que o ChaCha20-Poly1305?
Não em termos teóricos. Ambos oferecem 256 bits de segurança com chave de 256 bits e são considerados igualmente seguros contra todos os ataques criptográficos conhecidos em 2026. A diferença está na resistência prática a timing attacks em implementações de software: o ChaCha20 corre em tempo constante por design, enquanto o AES em software puro pode vazar informação de temporização através de acessos dependentes de dados à memória cache. Com AES-NI activo, esta diferença desaparece.
Qual usar no TLS 1.3?
O TLS 1.3 decide automaticamente com base no hardware disponível. Em servidores e clientes com AES-NI, stacks como OpenSSL e BoringSSL preferem TLS_AES_256_GCM_SHA384. Em dispositivos sem AES-NI, TLS_CHACHA20_POLY1305_SHA256 é priorizado. Para uma aplicação web típica, não é necessário forçar a cipher suite manualmente. O protocolo optimiza automaticamente por hardware.
O que é o XChaCha20 e quando usar?
O XChaCha20-Poly1305 é uma variante do ChaCha20-Poly1305 com nonce de 192 bits em vez de 96 bits. O nonce alargado torna seguro gerar nonces aleatoriamente mesmo para volumes muito elevados de mensagens, eliminando o risco de colisão de nonces. É recomendado para gestores de palavras-passe, cofres de dados distribuídos e qualquer aplicação onde a gestão manual de nonces seja complexa. O NordPass adoptou o XChaCha20 por esta razão específica.
O ChaCha20-Poly1305 está disponível nativamente no Node.js?
Parcialmente. O módulo crypto nativo do Node.js suporta chacha20-poly1305 através do OpenSSL, mas a API não é tão directa como para o AES-GCM. Para uso prático em produção, a biblioteca @noble/ciphers oferece uma interface limpa para ChaCha20-Poly1305 e XChaCha20-Poly1305 em JavaScript/TypeScript puro, com zero dependências externas e auditada pela Trail of Bits.
O WireGuard pode usar AES-256-GCM?
O WireGuard padrão usa exclusivamente ChaCha20-Poly1305 e não suporta negociação de cipher suite por design, para eliminar ataques de downgrade. Existe investigação activa em variantes “WireGuard-AES” para servidores de alto desempenho onde o AES acelerado seria vantajoso, com resultados publicados em 2025, mas essas variantes não fazem parte do protocolo WireGuard oficial.
Qual o impacto da computação quântica nestes algoritmos?
O algoritmo de Grover reduz a segurança das cifras simétricas de N bits para N/2 bits. Com chave de 256 bits, tanto o AES-256 como o ChaCha20 mantêm 128 bits de segurança pós-quântica, suficiente para os próximos 30 ou mais anos segundo o NIST. A ameaça quântica urgente são os algoritmos assimétricos (RSA, ECC), não as cifras simétricas. O NIST padronizou ML-KEM (Kyber) e ML-DSA (Dilithium) para substituição de RSA e ECDSA, mas AES-256 e ChaCha20 continuam válidos sem modificações.
Posso usar os dois algoritmos em simultâneo?
Sim, e o TLS 1.3 já faz exactamente isto. Em protocolos personalizados, é possível implementar negociação de cipher suite semelhante, usando um campo de versão ou identificador de algoritmo no envelope de mensagem. Esta abordagem maximiza a compatibilidade com hardware heterogéneo mantendo performance óptima em cada dispositivo. O campo de versão deve ser autenticado (incluído nos dados associados do AEAD) para prevenir ataques de downgrade.
