Cómo funcionan las claves de cifrado: base de la seguridad

Una clave de cifrado es una cadena de bits aleatorios que bloquea y desbloquea datos. Para la transferencia moderna de archivos, eso significa típicamente una clave AES de 256 bits —32 bytes de datos aleatorios generados por un generador de números aleatorios criptográficamente seguro (CSPRNG). El mismo algoritmo que convierte un vídeo de 10 GB en texto cifrado solo puede descifrarlo si recibe exactamente la misma clave. La seguridad de la clave es donde el cifrado vive o muere: un cifrado AES-256 perfecto no vale nada si la clave es débil, predecible o está expuesta. Este artículo explica cómo se crean, comparten, almacenan y destruyen las claves en servicios reales como HexaTransfer, Tresorit y Proton Drive.

Las claves son solo números aleatorios

Una clave de 256 bits son 32 bytes. Si generas una en el navegador, tiene este aspecto:

const key = crypto.getRandomValues(new Uint8Array(32));
// Uint8Array(32) [183, 45, 201, 77, ...]

Lo que la convierte en una «clave» es cómo la usa un algoritmo. AES-256-GCM toma una clave de 256 bits, la expande mediante un planificador de claves en 15 claves de ronda, y las usa para mezclar bloques de 128 bits a lo largo de 14 rondas. Las matemáticas no se preocupan por el origen de los bits: solo requiere que sean secretos e impredecibles.

«Impredecible» es la mitad más difícil. Si un atacante puede adivinar el estado de tu RNG, puede regenerar tu clave. El bug de Debian OpenSSL de 2006 redujo la entropía de las claves a 15 bits durante dos años antes de ser detectado: un ejemplo clásico de lo que pasa cuando falla la aleatoriedad.

Aleatoriedad criptográficamente segura

Los navegadores proporcionan crypto.getRandomValues(), que extrae del CSPRNG del sistema operativo: /dev/urandom en Linux, BCryptGenRandom en Windows, SecRandomCopyBytes en macOS. Estos a su vez mezclan múltiples fuentes de entropía — temporización de interrupciones, tiempos de búsqueda en disco, chips de RNG hardware como Intel RDRAND.

No uses Math.random() para claves. Es un Mersenne Twister predecible y su estado suele recuperarse a partir de unos pocos outputs.

En el servidor, crypto.randomBytes() en Node.js y secrets.token_bytes() en Python envuelven el CSPRNG del sistema operativo y son seguros. Los estándares NIST SP 800-90A y SP 800-90B definen los requisitos de CSPRNG; el kernel de Linux 5.17+ usa un diseño basado en BLAKE2s que los cumple.

Claves simétricas: una clave, dos direcciones

Los algoritmos simétricos como AES usan una clave para ambas direcciones. Las opciones de tamaño de clave:

• 128 bits — 2^128 valores posibles, seguro para la mayoría de propósitos, aprobado para SECRET por NSA CNSSP-15.
• 192 bits — poco común, usado en algunos contextos gubernamentales.
• 256 bits — 2^256 valores, aprobado para TOP SECRET, estándar actual para servicios de transferencia de archivos.

Doblar el tamaño de la clave no dobla la dificultad de fuerza bruta: la eleva al cuadrado. 2^128 ya está fuera de alcance (la edad del universo multiplicada por diez mil millones con todos los ordenadores de la Tierra). Los 256 bits son una cobertura frente a ordenadores cuánticos, donde el algoritmo de Grover reduce efectivamente a la mitad la fortaleza de las claves simétricas.

El problema difícil con las claves simétricas: cómo hacer llegar la misma clave a ambas partes sin que nadie la intercepte.

Claves asimétricas: el truco del par

La criptografía de clave pública resuelve la distribución de claves. Cada parte genera un par de claves matemáticamente vinculadas: una clave pública (compartida abiertamente) y una clave privada (mantenida en secreto). Cualquier cosa cifrada con la clave pública solo puede descifrarse con la clave privada.

Tipos comunes de claves asimétricas:

• RSA-2048 — módulo de 2048 bits, ampliamente compatible, lento. Usado en certificados TLS.
• RSA-4096 — más robusto, aún más lento.
• Curve25519 (X25519) — clave de curva elíptica de 256 bits, rápida, usada por Signal y WireGuard.
• Ed25519 — clave de firma de 256 bits, usada por SSH y la firma de commits de Git.

La clave privada por sí sola tiene entre 32 y 512 bytes dependiendo del algoritmo. Las claves privadas RSA son más grandes porque contienen múltiples primos; las claves privadas Curve25519 son solo 32 bytes aleatorios.

Híbrido: combinar ambas para sistemas reales

Ningún sistema práctico cifra archivos grandes directamente con RSA. En cambio, todos los protocolos reales —TLS, PGP, Age, Signal, cualquier servicio serio de transferencia de archivos— usan cifrado híbrido:

1. Genera una clave AES aleatoria de 256 bits («clave de sesión» o «clave de archivo»).
2. Cifra el archivo con AES-256-GCM.
3. Cifra la clave de sesión con la clave pública del destinatario.
4. Envía ambos.

El destinatario descifra la clave de sesión con su clave privada, luego la usa para descifrar el archivo. Obtienes la velocidad del cifrado simétrico y la conveniencia de distribución de claves del asimétrico.

Para la transferencia de archivos basada en navegador, la «clave pública» a menudo se reemplaza por el fragmento de URL: el remitente genera una clave de sesión, la incrusta en la URL después de #, y el navegador del destinatario la lee localmente. Más simple, y funciona sin que los destinatarios tengan un par de claves.

Derivar claves a partir de contraseñas

Los usuarios escriben contraseñas; los algoritmos quieren bits aleatorios uniformes. Una función de derivación de claves (KDF) los conecta:

• PBKDF2-HMAC-SHA-256 — itera una función hash. OWASP 2023 recomienda 600.000 iteraciones. Disponible en Web Crypto API.
• scrypt — resistente a la memoria, resiste ataques de GPU. Parámetros: N=2^17, r=8, p=1.
• Argon2id — mejor práctica actual, ganador de la Password Hashing Competition de 2015. Parámetros: memory=64 MB, iterations=3, parallelism=4.

Una KDF añade una salt (aleatoria, almacenada junto al texto cifrado) y un factor de trabajo (iteraciones) para ralentizar la fuerza bruta. Una contraseña aleatoria de 12 caracteres a través de Argon2id con 64 MB de memoria tarda miles de años a una granja de GPU en agotarla. Una contraseña débil como verano2024 cae en segundos independientemente de la KDF: la KDF no puede añadir entropía que no estaba ahí.

Almacenamiento de claves: ¿dónde viven las claves?

Las claves necesitan existir en algún lugar, y ese lugar es una decisión crítica para la seguridad:

• Memoria del navegador (solo sesión). El valor predeterminado para transferencias efímeras. La clave se genera, se usa y se descarta dentro de la carga de la página.
• Fragmento de URL. Compartida a través del enlace, almacenada en el historial del navegador del destinatario. Una vida útil limitada importa.
• Almacenamiento local / IndexedDB. Persistente pero accesible a cualquier JavaScript en el origen. Arriesgado a menos que esté cifrado con otra clave.
• Keychain del sistema operativo — macOS Keychain, Windows DPAPI, Linux libsecret. Respaldado por hardware en algunas plataformas.
• Módulo de seguridad hardware (HSM) — YubiKey, HSM en la nube (AWS CloudHSM, Azure Dedicated HSM). Las claves nunca salen del hardware.
• Servicio de gestión de claves (KMS) — AWS KMS, Google Cloud KMS, HashiCorp Vault. Centralizado, auditable, con un precio aproximado de 1 €/clave/mes.

Para la transferencia de archivos de conocimiento cero, la clave vive en el fragmento de URL y en el navegador del remitente. El servidor nunca la almacena.

Rotación y destrucción de claves

Las claves de larga duración acumulan riesgo. La mejor práctica es la rotación:

• Certificados TLS: rotación de 90 días (valor predeterminado de Let's Encrypt), máximo de 398 días para CAs públicas desde 2020.
• Claves de cifrado de datos: típicamente rotadas cada 90 días a 1 año en sistemas conformes (PCI DSS 4.0 Requisito 3.6).
• Claves maestras: rotadas anualmente o ante cambios de personal.

La destrucción también importa. Simplemente eliminar archivos de claves del disco no es suficiente: los SSD pueden retener datos en áreas de nivelación de desgaste. La destrucción segura requiere sobrescritura o comandos de eliminación de HSM dedicados. El borrado criptográfico —descartar la clave para que los datos cifrados se vuelvan permanentemente ilegibles— suele ser el enfoque más limpio para grandes volúmenes de datos.

Los servicios de transferencia de archivos típicamente usan claves por archivo que existen solo durante la vida útil de la transferencia (24 horas a 7 días) y se descartan junto con el texto cifrado al expirar.

Reconocer prácticas débiles de claves

Tres modos de fallo habituales a tener en cuenta:

• Claves codificadas en el código del cliente. Si la clave es la misma para todos los usuarios, no es una clave: es ofuscación.
• Claves almacenadas junto al texto cifrado en el mismo servidor o base de datos. Una brecha expone ambos.
• Sin rotación de claves. Los sistemas heredados con claves de cifrado de una década tienen aproximadamente una década de riesgo de brecha acumulado.

Un servicio de confianza publica un whitepaper criptográfico que cubre la generación, almacenamiento, rotación y destrucción de claves, y se somete a auditorías de terceros por empresas como Cure53 o Trail of Bits.

En perspectiva

Para compartir archivos sensibles: elige un servicio que genere claves de 256 bits en el cliente vía crypto.getRandomValues(), las incruste solo en el fragmento de URL (nunca enviadas al servidor), admita claves derivadas de contraseña vía PBKDF2 o Argon2id, y auto-expire tanto la clave como el texto cifrado en 24 horas.

Pruébalo en hexatransfer.com — gratis, sin cuenta, hasta 10 GB.