Primitivas criptográficas modernas: qué usar y qué evitar

Mapa mental: primitivas vs. problemas reales

En sistemas profesionales, casi nunca “usas criptografía” en abstracto: eliges primitivas concretas para resolver necesidades específicas (confidencialidad, integridad, autenticación, no repudio, derivación de claves, aleatoriedad). Una selección incorrecta suele fallar por: modo de operación inseguro, parámetros débiles, mala interoperabilidad o APIs que inducen errores.

• Cifrado simétrico: protege confidencialidad (y, si es AEAD, también integridad).
• Cifrado asimétrico: intercambio de claves, cifrado de pequeños secretos, autenticación basada en claves públicas.
• Funciones hash: huellas digitales, estructuras de datos (Merkle), identificación de contenido; no sirven como MAC.
• MAC/HMAC: integridad + autenticación con clave compartida.
• Firmas digitales: integridad + autenticación con clave pública + no repudio (según contexto legal/procedimental).
• KDF: derivar claves seguras desde secretos (contraseñas o material de clave).
• RNG/DRBG: generar claves, nonces, IVs, tokens; base de todo lo demás.

Criterios actuales de selección (qué mirar antes de elegir)

1) Seguridad práctica (construcción completa, no solo algoritmo)

• Preferir construcciones con seguridad moderna: AEAD para cifrado simétrico; OAEP/PSS para RSA; curvas modernas para ECC; hashes de la familia SHA-2/SHA-3.
• Evitar “componer a mano”: por ejemplo, “AES-CBC + HMAC” puede ser correcto, pero es fácil equivocarse en orden, verificación y manejo de IV; AEAD reduce superficie de error.
• Parámetros correctos: tamaños de clave, nonces únicos, etiquetas de contexto (AAD), longitudes de salida, etc.

2) Rendimiento y entorno

• Hardware: AES-GCM suele ser excelente con AES-NI; ChaCha20-Poly1305 suele rendir mejor en móviles/IoT sin aceleración AES.
• Latencia vs. throughput: firmas y KDF de contraseñas pueden ser costosas; planifica en función de tu carga.
• Restricciones: en embedded, el tamaño de código y RAM puede inclinar la balanza hacia primitivas más simples/compactas.

3) Soporte en librerías y APIs seguras

• Usa primitivas “de alto nivel” cuando existan: APIs de AEAD, cajas selladas (sealed boxes), libsodium/NaCl, o módulos bien mantenidos.
• Evita APIs de bajo nivel que exponen modos inseguros por defecto (p. ej., permitir ECB) o requieren demasiadas decisiones manuales.
• Mantenibilidad: elige lo que tu ecosistema soporta bien (rotación de claves, formatos estándar, validación).

4) Interoperabilidad y estandarización

• Protocolos: si integras con TLS/JWT/JOSE/PGP/etc., tus elecciones vienen condicionadas por lo que el estándar y la contraparte soportan.
• Formatos: define codificación (DER/PEM), endianness, longitudes y versionado de mensajes.
• Compatibilidad futura: evita algoritmos en retirada (SHA-1, RSA-PKCS#1 v1.5 para cifrado, etc.).

Tabla de elección: recomendada vs. aceptable vs. prohibida

Cifrado simétrico (AEAD): qué es y cómo usarlo bien

Concepto

El cifrado simétrico usa la misma clave para cifrar y descifrar. En sistemas modernos, la recomendación práctica es usar AEAD (Authenticated Encryption with Associated Data): cifra y autentica en una sola operación. Esto evita ataques por manipulación del ciphertext y reduce errores de implementación.

Casos de uso típicos

• Proteger payloads de API entre servicios (cuando no dependes solo de TLS).
• Cifrado de campos sensibles en base de datos (por registro/campo).
• Archivos o blobs en almacenamiento de objetos.

Guía práctica paso a paso (AEAD)

• 1) Elige algoritmo: AES-GCM si tienes aceleración AES; ChaCha20-Poly1305 si no.
• 2) Genera clave: 128 o 256 bits desde CSPRNG. No derives de contraseña con hash directo.
• 3) Define nonce/IV: debe ser único por clave (en GCM típicamente 96 bits). Nunca lo repitas.
• 4) Define AAD: metadatos no cifrados pero autenticados (p. ej., user_id, versión de esquema, tipo de mensaje).
• 5) Cifra: obtendrás ciphertext y tag (a veces concatenados).
• 6) Serializa: guarda/transporta nonce + aad (si aplica) + ciphertext + tag. El nonce no es secreto.
• 7) Descifra verificando: si la verificación del tag falla, rechaza sin filtrar detalles. No devuelvas plaintext parcial.

// Esquema de mensaje recomendado (ejemplo conceptual, no formato estándar): version || nonce || aad_len || aad || ciphertext || tag

Errores a evitar: reutilizar nonce con la misma clave (crítico en GCM), “cifrar y luego no autenticar”, o autenticar después de descifrar sin verificación estricta.

Cifrado asimétrico: úsalo para envolver claves, no para cifrar grandes datos

Concepto

El cifrado asimétrico usa un par de claves (pública/privada). Es más costoso que el simétrico y se usa típicamente para intercambiar o envolver una clave simétrica, o para cifrar secretos pequeños.

Casos de uso típicos

• Enviar una clave de sesión a un destinatario (envelope encryption).
• Proteger un secreto pequeño (p. ej., clave de API) para un receptor concreto.

Guía práctica paso a paso (envelope encryption con RSA-OAEP)

• 1) Genera una clave simétrica (DEK) con CSPRNG.
• 2) Cifra los datos con AEAD usando la DEK.
• 3) Envuelve la DEK con la clave pública del receptor usando RSA-OAEP (idealmente SHA-256).
• 4) Envía/almacena: wrapped_DEK + nonce + ciphertext + tag (+ AAD si aplica).
• 5) El receptor usa su clave privada para recuperar la DEK y descifrar.

Evitar: RSA-PKCS#1 v1.5 para cifrado, “RSA sin padding”, y cifrar directamente archivos grandes con RSA.

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

Funciones hash: huellas, no autenticación

Concepto

Una función hash toma un mensaje y produce un digest de longitud fija. Propiedades clave: resistencia a colisiones y preimagen (según el uso). Un hash no prueba autoría ni integridad frente a un atacante activo: cualquiera puede recalcularlo.

Casos de uso típicos

• Identificación de contenido (deduplicación, ETags, verificación de descargas).
• Commitments y estructuras tipo Merkle.
• Checksum de integridad en entornos no adversariales (con cuidado).

Evitar: MD5 y SHA-1 para seguridad (firmas, certificados, integridad adversarial). Para compatibilidad, solo en contextos no de seguridad y con justificación.

MAC y HMAC: integridad con clave compartida

Concepto

Un MAC autentica un mensaje usando una clave secreta compartida. HMAC (por ejemplo, HMAC-SHA-256) es robusto y ampliamente soportado. A diferencia del hash, un atacante sin la clave no puede forjar un tag válido.

Casos de uso típicos

• Firmar webhooks internos cuando no usas firmas asimétricas.
• Autenticar mensajes entre componentes que comparten secreto.
• Integridad de cookies/tokens opacos (si el diseño lo requiere).

Guía práctica paso a paso (HMAC)

• 1) Genera una clave aleatoria (≥ 128 bits, ideal 256 bits) desde CSPRNG.
• 2) Define canonicalización: exactamente qué bytes se firman (orden de campos, encoding). Esto evita discrepancias.
• 3) Calcula tag = HMAC(key, message_bytes).
• 4) Verifica con comparación constante (constant-time) para evitar filtraciones por timing.
• 5) Versiona el esquema (p. ej., prefijo v1) para rotaciones futuras.

// Anti-patrón (prohibido): SHA256(key || message)  // vulnerable a length extension en hashes Merkle-Damgård

Firmas digitales: autenticación con clave pública

Concepto

Una firma digital permite que cualquiera verifique (con la clave pública) que un mensaje fue firmado por quien posee la clave privada. A diferencia de HMAC, no requiere compartir secretos con verificadores.

Casos de uso típicos

• Distribución de software y verificación de artefactos.
• Tokens/veredictos verificables por múltiples servicios sin compartir secretos.
• Documentos y flujos donde necesitas verificabilidad pública.

Selección práctica

• Recomendado: Ed25519 por seguridad y ergonomía.
• Interoperabilidad: ECDSA P-256 es común en stacks corporativos.
• RSA: si se usa, preferir RSA-PSS con SHA-256 y tamaños adecuados.

Evitar: RSA “clásico” con PKCS#1 v1.5 en nuevos diseños, y cualquier esquema que dependa de RNG débil (ECDSA requiere nonces correctos; EdDSA reduce este riesgo al ser determinista).

KDF: derivación de claves (dos familias, dos objetivos)

1) KDF desde contraseña (password hashing)

Las contraseñas tienen baja entropía: necesitas una función lenta y con memoria para resistir ataques offline. Aquí encaja Argon2id (recomendado) o scrypt. PBKDF2 puede ser aceptable por compatibilidad, pero requiere parámetros altos.

Guía práctica paso a paso (Argon2id)

• 1) Genera salt único por usuario (≥ 16 bytes) con CSPRNG.
• 2) Elige parámetros: memoria (MB), iteraciones, paralelismo. Ajusta al hardware objetivo y latencia permitida.
• 3) Deriva un hash/clave de salida (p. ej., 32 bytes).
• 4) Almacena en formato que incluya parámetros + salt + resultado (muchas librerías lo serializan).
• 5) Verifica recalculando con los mismos parámetros y comparando en tiempo constante.
• 6) Plan de actualización: si subes parámetros, re-hash al próximo login.

2) KDF desde material de clave (HKDF)

Si ya tienes un secreto de alta entropía (p. ej., resultado de ECDH), usa HKDF para derivar múltiples claves con separación de propósito (encryption key, mac key, etc.).

• Casos de uso: derivar claves por sesión, por contexto, por “subclave” para distintos componentes.
• Buenas prácticas: usa info con etiquetas de contexto (p. ej., "serviceA->serviceB:v2") para evitar reutilización accidental.

RNG/DRBG: la primitiva silenciosa que rompe todo si falla

Concepto

Un generador criptográficamente seguro (CSPRNG) produce bytes impredecibles. Se usa para claves, nonces, salts, tokens de sesión y desafíos. Si la aleatoriedad es mala, incluso algoritmos “fuertes” se vuelven vulnerables.

Casos de uso típicos

• Claves simétricas y asimétricas.
• Nonces/IVs para AEAD.
• Salts para KDF de contraseñas.
• Tokens de reseteo, sesiones, CSRF.

Guía práctica paso a paso (RNG)

• 1) Usa el RNG del sistema operativo (API moderna) en lugar de uno propio.
• 2) No reutilices nonces: genera nonces aleatorios o usa contadores seguros según el modo (y documenta la estrategia).
• 3) No uses rand(), timestamps, UUIDv1, o “mezclas caseras”.
• 4) En entornos especiales (contenedores/VM/embedded), valida que la fuente de entropía esté disponible antes de generar claves.

Lista rápida de construcciones obsoletas o inseguras (para uso profesional)

• ECB para cualquier dato real: filtra patrones.
• “Cifrado sin autenticación”: confidencialidad sin integridad suele ser explotable.
• MD5 / SHA-1 para seguridad: colisiones prácticas/viables en escenarios reales.
• RSA sin OAEP (cifrado) o sin PSS (firmas) en diseños nuevos.
• 3DES, DES, RC4: obsoletos.
• Nonces repetidos en GCM/ChaCha20-Poly1305: puede comprometer confidencialidad e integridad.
• “Hash de contraseña” con SHA-256 (o similar) sin KDF de contraseña: vulnerable a cracking masivo.
• Comparación no constante de MAC/firmas: filtraciones por timing.

Guía de decisión por primitiva (checklist operativo)

Si necesitas cifrar datos

• ¿Puedes usar AEAD? Si sí: AES-GCM o ChaCha20-Poly1305.
• ¿Riesgo de reutilización de nonce (por concurrencia/bugs)? Considera AES-GCM-SIV si está disponible.
• Define formato de mensaje: incluye versión, nonce, AAD, ciphertext, tag.

Si necesitas integridad/autenticación entre dos sistemas con secreto compartido

• Usa HMAC-SHA-256.
• Define canonicalización y comparación constante.

Si necesitas verificabilidad pública o múltiples verificadores

• Usa firmas: Ed25519 (preferido) o ECDSA P-256 por interoperabilidad.
• Gestiona rotación y publicación de claves públicas (versionado).

Si partes de contraseñas

• Usa Argon2id con salt único y parámetros acordes al hardware.
• No reutilices salt, no uses hashes rápidos.

Si partes de un secreto fuerte (ECDH, master key)

• Usa HKDF-SHA-256 con info contextual para separar propósitos.

Si necesitas aleatoriedad

• Usa CSPRNG del SO.
• Documenta cómo generas nonces/IVs y cómo garantizas unicidad.