Capacidades de cifrado del navegador: lo que pueden hacer

Los navegadores modernos incluyen criptografía nativa que rivaliza con las librerías de seguridad dedicadas. Chrome, Firefox, Safari y Edge exponen todos la Web Crypto API (crypto.subtle), implementan TLS 1.3 con mecanismos de pinning de certificados, soportan WebAuthn y passkeys para autenticación resistente al phishing, aíslan cada origen con Site Isolation, y ofrecen almacenamiento de claves respaldado por hardware a través del TPM en Windows y el Secure Enclave en macOS/iOS. Para los desarrolladores que construyen herramientas de transferencia de archivos cifrados, esto significa que AES-256-GCM, la derivación de claves con PBKDF2 y la autenticación FIDO2 vienen incluidas sin necesidad de librería externa. Aquí está lo que cada navegador puede hacer realmente en 2026.

Web Crypto API: la base común

Los cuatro navegadores principales soportan la W3C Web Cryptography API con una superficie casi idéntica. Los algoritmos principales son:

Simétricos: AES-GCM, AES-CBC, AES-CTR, AES-KW (128, 192, 256 bits)
Asimétricos: RSA-OAEP, RSA-PSS, RSASSA-PKCS1-v1_5 (hasta 4096 bits), ECDSA y ECDH (P-256, P-384, P-521)
Hash: SHA-1, SHA-256, SHA-384, SHA-512
Derivación de claves: PBKDF2, HKDF
MAC: HMAC

Qué falta: ChaCha20-Poly1305 (sin soporte en ningún navegador), Argon2 (sin soporte en ningún navegador), Ed25519/X25519 (Safari 17+ y Firefox 129+ lo tienen, Chrome está alcanzando). Para esos primitivos sigues necesitando librerías JavaScript o WASM como libsodium.js o @noble/curves.

Chrome y Edge comparten la misma implementación criptográfica (BoringSSL a través de V8). Firefox usa NSS. Safari usa CoreCrypto, la librería validada por FIPS de Apple. El rendimiento varía: las iteraciones PBKDF2 de Firefox son aproximadamente un 20% más lentas que las de Chrome en hardware equivalente; AES-GCM de Safari con aceleración hardware en Apple Silicon es aproximadamente 2x más rápido que Chrome en el mismo Mac.

TLS 1.3 y Transparencia de Certificados

Todos los navegadores principales usan TLS 1.3 por defecto en los orígenes que lo soportan y se retrocompatibilizan a 1.2 solo para servidores heredados. Chrome eliminó el soporte de TLS 1.0 y 1.1 en Chrome 84 (julio de 2020). Firefox los eliminó en Firefox 78. Safari los abandonó en macOS 11 / iOS 14.

La Transparencia de Certificados se aplica obligatoriamente: los certificados emitidos después de abril de 2018 deben aparecer en al menos dos registros CT o Chrome y Safari los rechazarán. Esto detecta los ataques al estilo DigiNotar de forma temprana al hacer que las emisiones incorrectas de CA sean públicamente auditables. El pinning de claves públicas a través de la cabecera HPKP fue deprecado (Chrome 72 eliminó el soporte) porque habilitaba ataques de lockout. Las empresas que necesitan pinning aún lo tienen mediante el pinning de raíz de confianza en configuraciones gestionadas (MDM en macOS, políticas de Chrome Enterprise).

Aislamiento de origen y sandbox

Site Isolation de Chrome coloca cada origen en su propio proceso del sistema operativo desde 2018 (escritorio) y 2019 (Android). Fission de Firefox logra lo mismo desde Firefox 94. Safari usa el modelo por proceso de WebKit. Lo que esto significa para el cifrado: un script malicioso de origen cruzado no puede leer tu archivo descifrado desde la memoria de una pestaña hermana, porque la hermana vive en un proceso diferente con su propio heap.

Cross-Origin-Opener-Policy (COOP), Cross-Origin-Embedder-Policy (COEP) y Cross-Origin-Resource-Policy (CORP) permiten a las páginas optar por un aislamiento aún más estricto. Establecer Cross-Origin-Opener-Policy: same-origin y Cross-Origin-Embedder-Policy: require-corp habilita el aislamiento de origen cruzado, que a su vez desbloquea SharedArrayBuffer y temporizadores de alta resolución. Relevante para el cifrado porque los ataques de temporización al estilo Spectre contra las implementaciones AES se mitigan cuando el atacante no puede abrir un SAB en tu origen.

WebAuthn y passkeys para autenticación

FIDO2 WebAuthn está soportado en Chrome 67+, Firefox 60+, Safari 14+ y Edge 18+. Permite a las aplicaciones autenticar usuarios mediante claves hardware (YubiKey, Titan), autenticadores de plataforma (Face ID, Windows Hello, biométrico Android), o passkeys sincronizados en los dispositivos del usuario a través de iCloud Keychain, Google Password Manager o 1Password.

Para una aplicación de transferencia de archivos, WebAuthn reemplaza las contraseñas como el factor que protege el acceso a un enlace de compartición almacenado. Crucialmente, WebAuthn es resistente al phishing: la firma está vinculada al origen, así que un dominio similar no puede capturar credenciales. Chrome y Safari ambos se movieron a flujos con passkeys por defecto en 2023-2024, eliminando el requisito de clave física para la mayoría del uso de consumo.

Almacenamiento de claves respaldado por hardware

En Windows, el chip TPM 2.0 (obligatorio en Windows 11) puede almacenar claves Web Crypto generadas como no extraíbles a través del puente Windows CNG. En macOS e iOS, el Secure Enclave almacena las claves usadas para Face ID, Touch ID y passkeys. En Android, el Keystore respaldado por StrongBox (hardware) o TEE (Entorno de Ejecución Confiable) proporciona protección similar.

Lo que esto significa en la práctica: una clave generada como extractable: false mediante Web Crypto en un portátil moderno puede vivir en el TPM o Secure Enclave, no en la memoria principal. Incluso una explotación completa del navegador que vuelca la memoria JavaScript no produce los bytes crudos de la clave. Para herramientas de transferencia de archivos, esto es más útil para las claves de destinatario de larga duración; las claves AES efímeras por archivo no necesitan esta protección.

Content Security Policy como multiplicador criptográfico

El cifrado no sirve de nada si un script malicioso puede leer el texto en claro antes de cifrarse. Las cabeceras Content Security Policy permiten a un sitio declarar qué scripts tienen permitido ejecutarse. Una política estricta como:

Content-Security-Policy: default-src 'self'; script-src 'self' 'strict-dynamic' 'nonce-abc123';

bloquea los scripts inline y el código de terceros, sin dejar superficie de ataque para cargas útiles inyectadas que roben el cifrado. Todos los navegadores principales soportan CSP Nivel 3. Para aplicaciones de transferencia de archivos, combina CSP con Subresource Integrity (SRI) en cualquier script externo para garantizar que incluso el JS de terceros permitido no ha sido manipulado.

File System Access y OPFS

La File System Access API (Chrome 86+, Edge 86+, soporte parcial en Safari 15.2+ a través del Origin Private File System) permite a las aplicaciones web leer y escribir archivos locales con permiso del usuario. El Origin Private File System es especialmente relevante para el cifrado: es un sistema de archivos privado por origen, gestionado por el navegador, usado para almacenar en caché grandes cargas útiles cifradas antes de subir sin cargar todo en memoria.

Firefox ha sido más lento en adoptar FSA pero soporta OPFS desde Firefox 111. Safari soporta OPFS en general pero tiene un comportamiento más restrictivo en la File System Access API más amplia.

Lo que los navegadores todavía no hacen bien

Algunas lagunas persisten:

Argon2 para derivación de claves está ausente de Web Crypto. Usa librerías WASM para hash de contraseñas por encima de PBKDF2.
ChaCha20-Poly1305 no está expuesto. AES-GCM cubre la mayoría de necesidades, pero ChaCha ayudaría en dispositivos sin AES-NI (ARM antiguo).
Atestación de claves para claves respaldadas por hardware es limitada. WebAuthn proporciona atestación; la Web Crypto API más amplia no.
AEAD en streaming no es todavía parte de la especificación. El cifrado de archivos grandes requiere lógica de fragmentación o WASM.
Algoritmos post-cuánticos (Kyber, Dilithium) no están todavía en el navegador. Google ha enviado Kyber en los handshakes TLS (Chrome 116+) pero la criptografía post-cuántica expuesta a JavaScript sigue siendo territorio de librerías.

Qué usar hoy para transferencia de archivos

Una pila de transferencia de archivos basada en navegador creíble en 2026:

AES-256-GCM mediante crypto.subtle.encrypt para el contenido de los archivos
PBKDF2-SHA-256 a 600.000 iteraciones para claves derivadas de contraseña
crypto.getRandomValues() para salts y nonces (nunca Math.random)
Fragmentos de URL (#key=...) para pasar claves en el cliente sin exposición al servidor
HTTPS con TLS 1.3 mínimo, HSTS habilitado, COOP/COEP para aislamiento
CSP strict-dynamic, sin scripts inline
Passkeys WebAuthn para cualquier función con cuenta almacenada
OPFS para almacenamiento provisional de archivos grandes en Chrome/Edge/Safari 16+

HexaTransfer ejecuta esencialmente esta pila. También lo hacen SwissTransfer, Tresorit Send, Cryptpad y Proton Drive Share. Los primitivos son maduros y consistentes entre navegadores.

Prueba en todos los navegadores

Prueba siempre en los cuatro. Bugs reales: Firefox lanza OperationError en entradas PBKDF2 que Chrome acepta silenciosamente. FileReader de Safari es más lento con archivos de 2+ GB. La escritura en OPFS de Chrome se fragmenta por encima de 4 GB en algunas versiones. Los mensajes de verificación de usuario WebAuthn difieren significativamente (Face ID vs Touch ID vs Windows Hello vs biométrico Android). Usa BrowserStack, Sauce Labs o una matriz local de dispositivos físicos para pruebas previas al lanzamiento.

Los navegadores se han convertido silenciosamente en una de las plataformas de cifrado más completas disponibles. Los mismos primitivos basados en estándares que impulsan las aplicaciones bancarias, los gestores de contraseñas y los clientes de mensajería están a una sola llamada de JavaScript para cualquiera que construya herramientas de transferencia de archivos cifrados.

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