La mayoría de los equipos no necesitan un nuevo cifrado, necesitan valores predeterminados claros y la disciplina para aplicarlos consistentemente. Si eliges algoritmos por caso de uso, mantén las claves fuera del alcance y minimiza la vida útil de los datos, ya estarás por delante de la mayoría de las brechas en 2025.
Esta guía 101 es un mapa práctico. Explica los componentes básicos, luego te da valores predeterminados opinados para escenarios comunes para que puedas decidir qué usar y cuándo.
Comienza con tu objetivo y el estado de tus datos
Cada decisión de encriptación fluye de tres preguntas:
- Qué necesitas, confidencialidad, integridad, autenticidad, o las tres
- Dónde están los datos, en tránsito, en reposo, o en uso
- Contra quién te defiendes, un atacante externo, un administrador comprometido, una citación, o un proveedor malicioso
Responde estas y la selección se vuelve directa.
La respuesta rápida, valores predeterminados sensatos para 2025
- En tránsito, usa TLS 1.3 con suites de cifrado AEAD, por ejemplo AES‑GCM o ChaCha20‑Poly1305, y habilita el secreto hacia adelante. Ver RFC 8446.
- En reposo, usa AES‑256 con un modo autenticado. Para discos usa AES‑XTS, para archivos y objetos usa AES‑GCM. Envuelve las claves de datos con una clave maestra KMS y rota.
- Contraseñas, nunca cifres, hashea con Argon2id y sales únicos. Ajusta memoria, tiempo y paralelismo para tu hardware. Ver RFC 9106.
- Intercambio de claves, usa X25519 o ECDHE P‑256 para secreto hacia adelante. Ver RFC 7748.
- Firmas digitales, prefiere Ed25519 o ECDSA P‑256. Usa RSA 3072 solo si el cumplimiento o la herencia lo requieren.
- Transferencia de secretos de un solo uso a personas fuera del límite de tu sistema, usa enlaces cifrados del lado del cliente, autodestructivos con AEAD, expiración corta y una vista.
Si quieres una inmersión profunda en lenguaje sencillo sobre la encriptación simétrica misma, ve nuestra guía rápida a AES‑256 explicado para no ingenieros.
Entiende los componentes básicos
- Encriptación simétrica, una clave secreta para cifrar y descifrar. Rápida e ideal para datos en reposo. Ejemplo, AES‑256 en modo GCM.
- Encriptación asimétrica, dos claves, pública y privada. Útil para intercambio de claves y firmas. Ejemplo, X25519 para acuerdo de claves, Ed25519 para firmas.
- AEAD, encriptación autenticada con datos adicionales. Protege confidencialidad e integridad juntas. Ejemplos, AES‑GCM y ChaCha20‑Poly1305.
- Hashing y KDFs, funciones unidireccionales para verificación o derivación de claves. Usa Argon2id para contraseñas, HKDF para derivar subclaves.
- HMAC, autenticación de mensajes con una clave compartida. Usa HMAC‑SHA‑256 cuando necesites integridad sin confidencialidad.
OWASP tiene bases sólidas e independientes del proveedor en su Hoja de referencia de almacenamiento criptográfico y Hoja de referencia de almacenamiento de contraseñas.
Qué usar y cuándo, una hoja de referencia compacta
| Objetivo | Opción típica | Evitar | Notas |
|---|---|---|---|
| Tráfico web y API seguro | TLS 1.3 con AES‑GCM o ChaCha20‑Poly1305, ECDHE efímero | TLS heredado, intercambio de claves RSA estático, RC4, 3DES | Activa HSTS, considera mTLS dentro de tu perímetro, valida certificados correctamente. |
| Cifrar archivos u objetos en reposo | AES‑256‑GCM por objeto, claves gestionadas por KMS y encriptación de sobre | AES‑ECB, AES‑CBC sin autenticación, esquemas caseros | Almacena solo texto cifrado y metadatos, rota claves de datos, separa deberes para acceso a claves. |
| Cifrado de disco completo o volumen | AES‑XTS con claves fuertes | Sistema de archivos plano, cifrados antiguos o propietarios | Protege claves con TPM o HSM, bloquea cuando la máquina duerme, monitorea el riesgo de arranque en frío. |
| Almacenar contraseñas de usuario | Argon2id con sal por usuario, costo ajustado | SHA‑256 plano, SHA‑1, MD5, encriptación reversible | Considera un pimiento a nivel de aplicación almacenado en un HSM o KMS, limita la tasa y agrega MFA. |
| Protección a nivel de campo de base de datos | AES‑GCM con claves por registro o por inquilino, AE determinista opcional solo cuando debas indexar | Encriptación determinista para secretos, clave compartida en todos los inquilinos | Mantén nonces únicos, evita filtrar estructura, planea rotación de claves y trabajos de re‑encriptación. |
| Respaldos y archivos | AES‑256 AEAD, clave separada del respaldo, firma manifiestos | Respaldos sin cifrar, claves compartidas con producción | Mantén claves fuera del medio de respaldo, prueba restauraciones, rota y destruye medios retirados. |
| Firmas digitales | Ed25519 o ECDSA P‑256, RSA 3072 si es obligatorio | DSA, claves RSA pequeñas | Marca de tiempo de artefactos firmados, fija claves públicas donde sea posible. |
| Intercambio de claves | X25519 o ECDHE P‑256 | Intercambio de claves RSA estático | El secreto hacia adelante protege el tráfico pasado si una clave se filtra más tarde. |
| Transferencia de secretos de humano a humano | Enlace cifrado del lado del cliente, de un solo uso, autodestructivo | Correo electrónico, chat, tickets, sitios de pegado de larga duración | Minimiza la vida útil y las vistas, verifica el destinatario a través de un canal separado, mantén auditoría de eventos de acceso sin almacenar el secreto. |
Si tu caso de uso no encaja en la tabla, el método de selección es el mismo. Define el objetivo, elige un modo AEAD para confidencialidad más integridad, usa curvas modernas para intercambio de claves, y pon la gestión de claves primero.
La gestión de claves importa más que el cifrado
La guía de NIST sobre el ciclo de vida de las claves y la separación de roles es un buen ancla. Ver NIST SP 800‑57 Parte 1.
- Generación, usa la fuente aleatoria criptográfica del sistema operativo, nunca un PRNG personalizado.
- Almacenamiento, mantén las claves maestras en un KMS o HSM. Las aplicaciones deben recibir claves de datos de corta duración, a menudo a través de encriptación de sobre.
- Rotación, rota según un horario y por causa, y diseña para re‑encriptación segura sin tiempo de inactividad.
- Control de acceso y auditoría, restringe quién puede usar claves, registra cada uso. Separa entornos e inquilinos. Revisa registros regularmente.
- Retiro, destruye claves retiradas y vuelve el texto cifrado antiguo inaccesible a menos que explícitamente necesites descifrado a largo plazo.
Cuándo la encriptación del lado del servidor no es suficiente
La encriptación del lado del servidor protege contra una brecha de almacenamiento, pero no protege contra que el servicio mismo lea tus datos. Cuando tu modelo de amenazas incluye un administrador comprometido, un proveedor no confiable, o exposición a citación, mueve el límite de confianza al cliente con diseño de conocimiento cero.
La encriptación del lado del cliente significa que el texto plano se cifra en el dispositivo del remitente, el servidor solo ve texto cifrado, y la clave de descifrado nunca sale del contexto del remitente y destinatario. Para una introducción práctica sobre por qué esto importa, ve nuestro explicador sobre encriptación del lado del cliente vs. del servidor.
Este es exactamente el patrón para compartir secretos de un solo uso. Nurbak cifra secretos en el lado del remitente, produce un enlace de un solo uso, y destruye el texto cifrado después de que se lee. El acceso puede ser auditado sin almacenar nunca el secreto. Esa combinación, una vista, expiración corta, evento de auditoría, y conocimiento cero, reduce dramáticamente la exposición a largo plazo.
Valores predeterminados y parámetros prácticos en 2025
- AES‑GCM vs ChaCha20‑Poly1305, ambos son AEADs seguros. AES‑GCM es muy rápido en servidores con AES‑NI. ChaCha20‑Poly1305 es un valor predeterminado fuerte en móviles y embebidos donde la aceleración AES puede ser débil.
- Tamaños de clave, AES‑128 es aceptable, AES‑256 es un valor predeterminado conservador. Para RSA usa 3072 bits o más si debes. Para curvas elípticas prefiere P‑256 o la familia moderna 25519.
- Nonces e IVs, genera un nonce fresco y único por encriptación. Nunca reutilices nonces con AEAD.
- Parámetros de hash de contraseña, ajusta primero la memoria de Argon2id, luego iteraciones, luego paralelismo, para acercar la verificación a tu presupuesto de latencia mientras la mantienes costosa para los atacantes.
- Bibliotecas, prefiere implementaciones verificadas sobre código personalizado. Los ejemplos incluyen libsodium, BoringSSL o la API Web Crypto de la plataforma. Nunca copies fragmentos de código de foros aleatorios.
Errores comunes que causan brechas reales
- Cifrar sin autenticación, AES‑CBC sin un HMAC invita a la manipulación. Usa AEAD.
- Reutilizar IVs o nonces, esto puede romper completamente la confidencialidad con modos AEAD.
- Codificar claves o compartirlas entre inquilinos o entornos.
- "Cifrar" contraseñas en lugar de hacer hash con una función resistente a la memoria.
- Confiar en registros de correo electrónico o chat para mover credenciales. Estos canales son persistentes, buscables y a menudo respaldados.
- Construir tu propia criptografía o mezclar primitivas de formas novedosas. La composición es sutil y fácil de equivocar.
Un flujo de decisión simple
Ejemplos del mundo real
- Compartir una contraseña de base de datos con un proveedor, envía un enlace de conocimiento cero, de un solo uso con un límite de una vista y una expiración de 24 horas. Confirma la recepción a través de un canal separado. Rota la contraseña después del uso.
- Cifrar exportaciones de productos o PII antes de subida a la nube, cifra con AES‑GCM en el cliente, envuelve la clave de datos con tu KMS, almacena solo texto cifrado y metadatos.
- Asegurar llamadas internas de microservicios, aplica TLS 1.3 en todas partes, usa mTLS para confianza de servicio a servicio, fija raíces CA y automatiza la rotación de certificados.
- Almacenar contraseñas de usuario para inicio de sesión, usa Argon2id con sal por usuario, pimiento opcional a nivel de aplicación en un HSM. Monitorea intentos de inicio de sesión y aplica MFA.
Notas de cumplimiento
La encriptación fuerte ayuda a demostrar el debido cuidado para SOC 2, ISO 27001, GDPR e HIPAA. Los auditores buscarán algoritmos y parámetros documentados, gestión de claves, separación de deberes, y evidencia de rotación y revisión de acceso. Los patrones de conocimiento cero reducen la cantidad de datos sensibles que retienes, lo que reduce la exposición a brechas y multas.
Cómo encaja Nurbak
Nurbak se enfoca en una brecha específica pero riesgosa, compartir secretos ad-hoc de humano a humano. En lugar de colocar credenciales vivas en canales persistentes, Nurbak crea enlaces autodestructivos, cifrados del lado del cliente. Las características que apoyan este flujo de trabajo incluyen enlaces de acceso de un solo uso, encriptación AES‑256, arquitectura de conocimiento cero, sin registro o almacenamiento de datos, registros de acceso de auditoría, y un panel de administración con análisis para supervisión. Los secretos se cifran localmente y se eliminan permanentemente después de ser leídos, por lo que tus registros contienen solo enlaces muertos, no credenciales.
Si estás adoptando una postura de privacidad por defecto, esta es una victoria de alto apalancamiento porque elimina una fuente común de propagación de credenciales en correo electrónico, chat y tickets.
Preguntas frecuentes
Cuál es la diferencia entre encriptación y hash El hash es unidireccional y se usa para verificación, por ejemplo almacenamiento de contraseñas. La encriptación es bidireccional y se usa para confidencialidad. Cuando necesitas tanto confidencialidad como integridad, usa un modo AEAD como AES‑GCM.
Es AES‑256 siempre mejor que AES‑128 Ambos son seguros cuando se usan correctamente. AES‑256 ofrece un margen de seguridad mayor. El rendimiento y el soporte de la plataforma a veces favorecen AES‑128. La mayoría de los equipos estandarizan en AES‑256 por simplicidad.
Deberíamos seguir usando RSA Usa curvas elípticas para sistemas nuevos, por ejemplo X25519 para intercambio de claves y Ed25519 para firmas. Usa RSA 3072 solo si debes admitir herencia o un mandato de cumplimiento. Evita el intercambio de claves RSA estático.
Cómo elijo los parámetros de Argon2id Haz referencia en tu hardware de producción. Objetiva un tiempo de verificación que sea aceptable para inicio de sesión mientras sea costoso para los atacantes. Aumenta la memoria primero, luego iteraciones. Ve la guía en RFC 9106.
Puedo cifrar en la base de datos y aún consultar Sí, pero es una compensación. La encriptación determinista permite consultas de igualdad pero filtra duplicados. Manténlo en campos de bajo riesgo, nunca en secretos, y aísla claves por inquilino o tabla.
Qué pasa con las mejores prácticas de gestión de claves Usa un KMS o HSM, nunca almacenes claves maestras en la configuración de la aplicación. Rota rutinariamente y por causa. Registra cada uso de clave y revisa el acceso. Ver NIST SP 800‑57 Parte 1.
Cómo aseguro llamadas internas de servicio a servicio Aplica TLS 1.3 en todas partes con secreto hacia adelante. Prefiere ECDHE con X25519 o P‑256, y cifrados AEAD. Considera TLS mutuo para autenticación. Ver RFC 8446 y RFC 7748.
¿Listo para eliminar credenciales vivas del correo electrónico y chat sin ralentizar a tu equipo? Crea un enlace cifrado de conocimiento cero y de un solo uso con Nurbak en segundos en Nurbak.