A maioria das equipes não precisa de um novo cifrador, elas precisam de padrões claros e a disciplina para aplicá-los consistentemente. Se você escolher algoritmos por caso de uso, mantiver as chaves fora de alcance e minimizar a vida útil dos dados, já estará à frente da maioria das violações em 2025.
Este guia 101 é um mapa prático. Explica os componentes básicos, depois oferece padrões opinativos para cenários comuns para que você possa decidir o que usar e quando.
Comece com seu objetivo e o estado dos seus dados
Toda decisão de criptografia decorre de três perguntas:
- O que você precisa, confidencialidade, integridade, autenticidade, ou os três
- Onde estão os dados, em trânsito, em repouso, ou em uso
- Contra quem você está se defendendo, um atacante externo, um administrador comprometido, uma intimação, ou um fornecedor malicioso
Responda essas e a seleção se torna direta.
A resposta rápida, padrões sensatos para 2025
- Em trânsito, use TLS 1.3 com suites de cifra AEAD, por exemplo AES‑GCM ou ChaCha20‑Poly1305, e habilite sigilo futuro. Ver RFC 8446.
- Em repouso, use AES‑256 com um modo autenticado. Para discos use AES‑XTS, para arquivos e objetos use AES‑GCM. Envolva chaves de dados com uma chave mestra KMS e rotacione.
- Senhas, nunca criptografe, faça hash com Argon2id e salts únicos. Ajuste memória, tempo e paralelismo para seu hardware. Ver RFC 9106.
- Troca de chaves, use X25519 ou ECDHE P‑256 para sigilo futuro. Ver RFC 7748.
- Assinaturas digitais, prefira Ed25519 ou ECDSA P‑256. Use RSA 3072 apenas se conformidade ou legado exigir.
- Transferência de segredos de uso único para pessoas fora do limite do seu sistema, use links criptografados do lado do cliente, autodestrutivos com AEAD, expiração curta e uma visualização.
Se você quer uma imersão profunda em linguagem simples sobre criptografia simétrica em si, veja nosso guia rápido para AES‑256 explicado para não engenheiros.
Entenda os componentes básicos
- Criptografia simétrica, uma chave secreta para criptografar e descriptografar. Rápida e ideal para dados em repouso. Exemplo, AES‑256 no modo GCM.
- Criptografia assimétrica, duas chaves, pública e privada. Útil para troca de chaves e assinaturas. Exemplo, X25519 para acordo de chaves, Ed25519 para assinaturas.
- AEAD, criptografia autenticada com dados adicionais. Protege confidencialidade e integridade juntas. Exemplos, AES‑GCM e ChaCha20‑Poly1305.
- Hash e KDFs, funções unidirecionais para verificação ou derivação de chaves. Use Argon2id para senhas, HKDF para derivar subchaves.
- HMAC, autenticação de mensagens com uma chave compartilhada. Use HMAC‑SHA‑256 quando precisar de integridade sem confidencialidade.
OWASP tem bases sólidas e independentes de fornecedor em sua Folha de referência de armazenamento criptográfico e Folha de referência de armazenamento de senhas.
O que usar e quando, uma folha de referência compacta
| Objetivo | Escolha típica | Evitar | Notas |
|---|---|---|---|
| Tráfego web e API seguro | TLS 1.3 com AES‑GCM ou ChaCha20‑Poly1305, ECDHE efêmero | TLS legado, troca de chaves RSA estática, RC4, 3DES | Ative HSTS, considere mTLS dentro do seu perímetro, valide certificados adequadamente. |
| Criptografar arquivos ou objetos em repouso | AES‑256‑GCM por objeto, chaves gerenciadas por KMS e criptografia de envelope | AES‑ECB, AES‑CBC sem autenticação, esquemas caseiros | Armazene apenas texto cifrado e metadados, rotacione chaves de dados, separe deveres para acesso a chaves. |
| Criptografia de disco completo ou volume | AES‑XTS com chaves fortes | Sistema de arquivos simples, cifras antigas ou proprietárias | Proteja chaves com TPM ou HSM, bloqueie quando a máquina dormir, monitore risco de inicialização a frio. |
| Armazenar senhas de usuário | Argon2id com sal por usuário, custo ajustado | SHA‑256 simples, SHA‑1, MD5, criptografia reversível | Considere um pimenta a nível de aplicação armazenado em um HSM ou KMS, limite de taxa e adicione MFA. |
| Proteção no nível de campo do banco de dados | AES‑GCM com chaves por registro ou por inquilino, AE determinístico opcional apenas quando você deve indexar | Criptografia determinística para segredos, chave compartilhada em todos os inquilinos | Mantenha nonces únicos, evite vazar estrutura, planeje rotação de chaves e trabalhos de re‑criptografia. |
| Backups e arquivos | AES‑256 AEAD, chave separada do backup, assine manifestos | Backups não criptografados, chaves compartilhadas com produção | Mantenha chaves fora da mídia de backup, teste restaurações, rotacione e destrua mídia retirada. |
| Assinaturas digitais | Ed25519 ou ECDSA P‑256, RSA 3072 se obrigatório | DSA, chaves RSA pequenas | Carimbo de data/hora de artefatos assinados, fixe chaves públicas onde possível. |
| Troca de chaves | X25519 ou ECDHE P‑256 | Troca de chaves RSA estática | Sigilo futuro protege tráfego passado se uma chave vazar mais tarde. |
| Transferência de segredos de humano para humano | Link criptografado do lado do cliente, de uso único, autodestrutivo | E-mail, chat, tickets, sites de colagem de longa duração | Minimize tempo de vida e visualizações, verifique destinatário via canal separado, mantenha auditoria de eventos de acesso sem armazenar o segredo. |
Se seu caso de uso não se encaixa na tabela, o método de seleção é o mesmo. Defina o objetivo, escolha um modo AEAD para confidencialidade mais integridade, use curvas modernas para troca de chaves, e coloque gerenciamento de chaves primeiro.
Gerenciamento de chaves importa mais que o cifrador
A orientação do NIST sobre ciclo de vida de chaves e separação de funções é uma boa âncora. Ver NIST SP 800‑57 Parte 1.
- Geração, use a fonte aleatória criptográfica do SO, nunca um PRNG personalizado.
- Armazenamento, mantenha chaves mestras em um KMS ou HSM. Aplicações devem receber chaves de dados de curta duração, frequentemente via criptografia de envelope.
- Rotação, rotacione em um cronograma e por causa, e projete para re‑criptografia segura sem tempo de inatividade.
- Controle de acesso e auditoria, restrinja quem pode usar chaves, registre cada uso. Separe ambientes e inquilinos. Revise registros regularmente.
- Aposentadoria, destrua chaves aposentadas e torne texto cifrado antigo inacessível a menos que você explicitamente precise de descriptografia de longo prazo.
Quando criptografia do lado do servidor não é suficiente
A criptografia do lado do servidor protege contra uma violação de armazenamento, mas não protege contra o próprio serviço ler seus dados. Quando seu modelo de ameaça inclui um administrador comprometido, um fornecedor não confiável ou exposição a intimação, mova o limite de confiança para o cliente com design de conhecimento zero.
Criptografia do lado do cliente significa que texto plano é criptografado no dispositivo do remetente, o servidor vê apenas texto cifrado, e a chave de descriptografia nunca sai do contexto do remetente e destinatário. Para uma introdução prática sobre por que isso importa, veja nosso explicador sobre criptografia do lado do cliente vs. do servidor.
Este é exatamente o padrão para compartilhamento de segredos de uso único. O Nurbak criptografa segredos no lado do remetente, produz um link de uso único, e destrói o texto cifrado após ser lido. O acesso pode ser auditado sem nunca armazenar o segredo. Essa combinação, uma visualização, expiração curta, evento de auditoria, e conhecimento zero, reduz drasticamente a exposição de longo prazo.
Padrões e parâmetros práticos em 2025
- AES‑GCM vs ChaCha20‑Poly1305, ambos são AEADs seguros. AES‑GCM é muito rápido em servidores com AES‑NI. ChaCha20‑Poly1305 é um padrão forte em móveis e embarcados onde aceleração AES pode ser fraca.
- Tamanhos de chave, AES‑128 é aceitável, AES‑256 é um padrão conservador. Para RSA use 3072 bits ou mais se precisar. Para curvas elípticas prefira P‑256 ou a família moderna 25519.
- Nonces e IVs, gere um nonce fresco e único por criptografia. Nunca reutilize nonces com AEAD.
- Parâmetros de hash de senha, ajuste memória de Argon2id primeiro, depois iterações, depois paralelismo, para aproximar verificação do seu orçamento de latência enquanto a mantém cara para atacantes.
- Bibliotecas, prefira implementações verificadas sobre código personalizado. Exemplos incluem libsodium, BoringSSL ou a API Web Crypto da plataforma. Nunca copie fragmentos de código de fóruns aleatórios.
Erros comuns que causam violações reais
- Criptografar sem autenticação, AES‑CBC sem um HMAC convida a adulteração. Use AEAD.
- Reutilizar IVs ou nonces, isso pode quebrar completamente confidencialidade com modos AEAD.
- Codificar chaves ou compartilhá-las entre inquilinos ou ambientes.
- "Criptografar" senhas em vez de fazer hash com uma função resistente à memória.
- Confiar em registros de e-mail ou chat para mover credenciais. Esses canais são persistentes, pesquisáveis e frequentemente backup.
- Construir sua própria criptografia ou misturar primitivas de formas novas. Composição é sutil e fácil de errar.
Um fluxo de decisão simples
Exemplos do mundo real
- Compartilhar uma senha de banco de dados com um fornecedor, envie um link de conhecimento zero, de uso único com limite de uma visualização e expiração de 24 horas. Confirme recebimento via canal separado. Rotacione a senha após o uso.
- Criptografar exportações de produtos ou PII antes do upload na nuvem, criptografe com AES‑GCM no cliente, envolva a chave de dados com seu KMS, armazene apenas texto cifrado e metadados.
- Proteger chamadas internas de microserviços, aplique TLS 1.3 em todos os lugares, use mTLS para confiança de serviço a serviço, fixe raízes CA e automatize rotação de certificados.
- Armazenar senhas de usuário para login, use Argon2id com sal por usuário, pimenta opcional a nível de aplicação em um HSM. Monitore tentativas de login e aplique MFA.
Notas de conformidade
Criptografia forte ajuda a demonstrar cuidado devido para SOC 2, ISO 27001, GDPR e HIPAA. Auditores procurarão algoritmos e parâmetros documentados, gerenciamento de chaves, separação de funções, e evidência de rotação e revisão de acesso. Padrões de conhecimento zero reduzem a quantidade de dados sensíveis que você retém, o que reduz exposição a violações e multas.
Como o Nurbak se encaixa
O Nurbak foca em uma lacuna específica mas arriscada, compartilhamento ad-hoc de segredos de humano para humano. Em vez de colocar credenciais vivas em canais persistentes, o Nurbak cria links autodestrutivos, criptografados do lado do cliente. Recursos que suportam este fluxo de trabalho incluem links de acesso de uso único, criptografia AES‑256, arquitetura de conhecimento zero, sem registro ou armazenamento de dados, registros de acesso de auditoria, e um painel de administração com análises para supervisão. Segredos são criptografados localmente e permanentemente excluídos após serem lidos, então seus registros contêm apenas links mortos, não credenciais.
Se você está adotando uma postura de privacidade por padrão, esta é uma vitória de alta alavancagem porque elimina uma fonte comum de proliferação de credenciais em e-mail, chat e tickets.
Perguntas frequentes
Qual é a diferença entre criptografia e hash Hash é unidirecional e usado para verificação, por exemplo armazenamento de senhas. Criptografia é bidirecional e usada para confidencialidade. Quando você precisa tanto de confidencialidade quanto integridade, use um modo AEAD como AES‑GCM.
AES‑256 é sempre melhor que AES‑128 Ambos são seguros quando usados corretamente. AES‑256 oferece uma margem de segurança maior. Desempenho e suporte de plataforma às vezes favorecem AES‑128. A maioria das equipes padroniza em AES‑256 por simplicidade.
Devemos ainda usar RSA Use curvas elípticas para sistemas novos, por exemplo X25519 para troca de chaves e Ed25519 para assinaturas. Use RSA 3072 apenas se precisar suportar legado ou um mandato de conformidade. Evite troca de chaves RSA estática.
Como escolho parâmetros de Argon2id Faça referência no seu hardware de produção. Objetive um tempo de verificação aceitável para login enquanto caro para atacantes. Aumente memória primeiro, depois iterações. Veja a orientação em RFC 9106.
Posso criptografar no banco de dados e ainda consultar Sim, mas é uma compensação. Criptografia determinística permite consultas de igualdade mas vaza duplicatas. Mantenha em campos de baixo risco, nunca em segredos, e isole chaves por inquilino ou tabela.
E as melhores práticas de gerenciamento de chaves Use um KMS ou HSM, nunca armazene chaves mestras na configuração da aplicação. Rotacione rotineiramente e por causa. Registre cada uso de chave e revise acesso. Ver NIST SP 800‑57 Parte 1.
Como protejo chamadas internas de serviço a serviço Aplique TLS 1.3 em todos os lugares com sigilo futuro. Prefira ECDHE com X25519 ou P‑256, e cifras AEAD. Considere TLS mútuo para autenticação. Ver RFC 8446 e RFC 7748.
Pronto para remover credenciais vivas de e-mail e chat sem desacelerar sua equipe? Crie um link criptografado de conhecimento zero e de uso único com o Nurbak em segundos em Nurbak.