Validador de IV de Cifra (Hex)

O que e um IV e por que ele importa

Um Initialization Vector (IV) — também chamado nonce em cifras de fluxo — e o valor aleatório ou único que da comportamento probabilistico as cifras simetricas modernas. Sem ele, criptografar o mesmo texto com a mesma chave geraria sempre o mesmo ciphertext, vazando padrões. Padrões como AES-CBC, AES-GCM, AES-CTR e ChaCha20-Poly1305 exigem IV em toda criptografia e, na maioria deles, ele deve ser único por chave durante a vida útil da chave.

Este validador inspeciona um IV em hexadecimal: confere o alfabeto (0-9a-fA-F), conta bytes e informa se o tamanho bate com o algoritmo escolhido — 16 bytes (32 caracteres hex) para AES-CBC e bloco do AES, 12 bytes (24 hex) para AES-GCM e ChaCha20-Poly1305, 8 bytes (16 hex) para o legado DES/3DES.

Tamanho de IV por algoritmo

• AES-CBC: IV de 128 bits = 16 bytes = 32 hex. Precisa ser imprevisivel (CSPRNG), não so único.
• AES-GCM: IV recomendado de 96 bits (12 bytes = 24 hex). IVs maiores forcam derivacao via GHASH que reduz a margem de segurança.
• AES-CTR: tipicamente nonce de 96 bits + contador de 32 bits. O contador não da volta dentro da mesma mensagem.
• ChaCha20-Poly1305: nonce de 96 bits (12 bytes), mesma forma do GCM.
• DES / 3DES-CBC: IV de 64 bits (8 bytes = 16 hex). So legado — ambas as cifras estão formalmente obsoletas.
• XChaCha20-Poly1305: nonce de 192 bits (24 bytes = 48 hex), grande o bastante para gerar aleatório com segurança.

Por que reusar IV e catastrofico

Reusar IV com a mesma chave e uma das falhas criptograficas mais devastadoras. Em AES-CBC, pares (chave, IV) iguais revelam se dois textos compartilham prefixo. No AES-GCM as consequencias são piores: um único reuso vaza a chave de autenticação H, permitindo ao atacante forjar mensagens, não so decriptar. O desastre do ECDSA do PS3 da Sony (2010) e parente: reusar o número aleatório por mensagem revelou a chave de assinatura. Carteiras Bitcoin e implementações TLS ja sofreram o mesmo.

Como gerar IV corretamente

Sempre use um CSPRNG — gerador pseudo-aleatório criptograficamente seguro — e nunca Math.random(), rand(), timestamp ou hash da senha. Idiomas de referência:

// Node.js
const iv = require('crypto').randomBytes(12);

# Python
import secrets
iv = secrets.token_bytes(12)

// Go
iv := make([]byte, 12); _, _ = rand.Read(iv)

// Browser
const iv = crypto.getRandomValues(new Uint8Array(12));

Para chaves de vida longa que protegem muitas mensagens, prefira um contador deterministico ou o modo SIV (RFC 5297, AES-SIV), que sobrevive a reuso de nonce. A NIST SP 800-38D fixa os limites formais: com nonces aleatórios de 96 bits, no máximo 2^32 mensagens por chave antes de re-keying.

Hex, base64 e bytes brutos

O IV e apenas uma string de bytes; a codificação e escolha de apresentacao. Hex e amigável para log e debug (dobra o tamanho). Base64 e base64url são comuns em JWT (campo iv do JWE), URLs e payloads de API (4 chars por 3 bytes). Bytes brutos aparecem em protocolos binarios (TLS records, Signal). A cifra em si não se importa — so a camada de empacotamento. Um IV GCM de 12 bytes vira 24 hex, 16 base64 (com padding) ou 16 bytes na rede. O Banco Central, ao normatizar criptografia do PIX, exige formato bem definido por payload — geralmente hex em arquivos de homologação e binario nas mensagens reais.

Anti-padrões comuns a evitar

• IV hardcoded no código: const iv = "000102030405060708090a0b"; — visível em qualquer decompilacao.
• IV derivado da senha: colapsa para o mesmo valor sempre, quebrando o GCM.
• Mesmo IV em todos os registros: clássico em criptografia de campo de banco "para permitir busca". Destroi a confidencialidade.
• Armazenar IV separado do ciphertext: convida a inconsistencias. O layout convencional e iv || ciphertext || tag em um único blob.
• AES-CBC sem MAC: abre porta para padding oracle. Sempre use criptografia autenticada (GCM, ChaCha20-Poly1305, AES-CBC + HMAC).

FAQ

Posso reusar IV com a mesma chave? Nunca — no AES-GCM um único reuso destroi a autenticidade. Se precisa de criptografia determinística, use AES-SIV (RFC 5297), que foi desenhado para isso.

CSPRNG e mesmo obrigatório? Sim. Math.random() e rand() tem seed previsivel e podem ser replicados por quem observar algumas saidas. Use entropia do SO (/dev/urandom, BCryptGenRandom, SecRandomCopyBytes).

Qual tamanho ideal de IV no AES-GCM? Exatamente 96 bits (12 bytes). Qualquer outro tamanho aciona uma derivacao extra por GHASH que enfraquece a prova de segurança. Os mesmos 96 bits valem para ChaCha20-Poly1305.

O IV precisa ser secreto? Não. O IV e público: viaja junto do ciphertext. Ele precisa ser único (e, no CBC, imprevisivel), não confidencial.

Por que a NIST desencoraja AES-CBC em sistemas novos? CBC não tem autenticação embutida e e vulneravel a padding oracle quando combinado ingenuamente com PCKS7. A orientacao atual aponta para AES-GCM, AES-GCM-SIV, ChaCha20-Poly1305 ou AES-OCB.