Geração segura de chaves, nonces e IVs

Três valores criptográficos distintos precisam de geração segura: (1) Chaves — de longa duração, devem ser imprevisíveis e secretas. (2) IVs — por mensagem, podem ser públicos, mas devem ser imprevisíveis (CBC) ou exclusivos (GCM). (3) Nonces — devem ser exclusivos a cada uso, mas podem ou não ser aleatórios.

AES-128: secrets.token_bytes(16). AES-256: secrets.token_bytes(32). ChaCha20: secrets.token_bytes(32). Nunca derive chaves de senhas sem uma KDF (PBKDF2/Argon2). Nunca reutilize chaves entre algoritmos ou finalidades diferentes.

from cryptography.hazmat.primitives.asymmetric import ec, rsa rsa_key = rsa.generate_private_key(public_exponent=65537, key_size=2048) ec_key = ec.generate_private_key(ec.SECP256R1()) # A biblioteca gerencia internamente a obtenção de entropia

O AES-CBC exige um IV de 16 bytes uniformemente aleatório por mensagem. Nunca reutilize um IV com a mesma chave. Nunca use um contador como IV no modo CBC. Gere-o assim: iv = os.urandom(16). Acrescente o IV ao início do texto cifrado — ele não precisa ser secreto, apenas imprevisível.

O AES-GCM exige um nonce de 96 bits exclusivo para cada par (chave, mensagem). A reutilização de nonce compromete catastroficamente o GCM: o invasor recupera a chave de autenticação e pode forjar mensagens. Use um nonce aleatório de 12 bytes (limite do aniversário em 2^32 mensagens) ou um contador.

Para criptografia de alto volume com uma única chave: mantenha um contador persistente por chave. nonce = counter.to_bytes(12, "big"). Incremente o contador após cada criptografia. Armazene o contador em armazenamento persistente — redefini-lo após uma reinicialização causa reutilização.

AES-GCM-SIV e Deoxys-II são resistentes ao uso indevido de nonce: a reutilização de nonce degrada a segurança ao nível da criptografia determinística (sem vazamento da chave de autenticação). São recomendados quando é difícil garantir a exclusividade dos nonces (sistemas distribuídos, cenários de falha e reinicialização).

Não use material de chave bruto diretamente para várias finalidades. Derive chaves específicas para cada finalidade: from cryptography.hazmat.primitives.kdf.hkdf import HKDF. hkdf = HKDF(SHA256(), 32, salt, info=b"enc_key"). key = hkdf.derive(master_key). Use um valor info diferente para cada finalidade.

Derive chaves específicas para cada sessão a partir de um segredo compartilhado (por exemplo, uma saída de ECDH) usando HKDF. O TLS 1.3 deriva chaves separadas de cliente e servidor para o handshake e os dados da aplicação. As chaves de sessão isolam o comprometimento: descobrir uma chave de sessão não revela nada sobre as outras.

Para armazenar uma chave com segurança, envolva-a com uma Key Encryption Key (KEK) usando AES-KW (RFC 3394) ou AES-GCM. A chave envolvida pode ser armazenada em um banco de dados ou transmitida. A KEK é armazenada em um HSM ou em um armazenamento de chaves protegido por hardware (Android Keystore, Apple Secure Enclave).

Antes da implantação, verifique: (1) todas as chaves são provenientes de os.urandom/secrets. (2) Não há chaves/IVs codificados diretamente. (3) IVs nunca são reutilizados com a mesma chave. (4) Nonces do GCM são exclusivos por mensagem. (5) O cronograma de rotação de chaves está definido. (6) A derivação de chaves usa HKDF com valores info distintos.

Qual é a consequência de reutilizar um nonce no AES-GCM?

As chaves precisam de geração verdadeiramente aleatória; os IVs do CBC precisam de aleatoriedade; os nonces do GCM precisam de exclusividade. Use os.urandom/secrets, faça a derivação com HKDF e envolva as chaves com KEKs. AEADs resistentes ao uso indevido de nonce protegem contra reutilização acidental. A seguir: provas de conhecimento zero.