Cifrado AES — cifrar texto en el navegador

¿Qué hace exactamente esta herramienta?

Usted introduce un texto claro y una passphrase, la herramienta cifra ambos con AES — simétricamente, es decir, la misma clave sirve para cifrar y descifrar. En modo Descifrar invierte el proceso. Todo se ejecuta íntegramente en su navegador vía la Web Cryptography API, una interfaz estandarizada por el W3C que cada navegador moderno incluye desde aproximadamente 2015. Ningún ida y vuelta al servidor, ninguna cuenta, ningún tracking. Puede cargar la página sin conexión (PWA) y la herramienta sigue funcionando.

Salida en Base64 (compacto, útil para correo/chat) o Hex (útil para logs y diffs de depuración). La salida agrupa tres elementos consecutivos: una sal aleatoria para la derivación de clave, un vector de inicialización (IV) aleatorio y el ciphertext propiamente dicho. La disposición está documentada explícitamente para que pueda descifrar el ciphertext con OpenSSL, Python o cualquier otra pila compatible con AES.

¿Por qué AES en el navegador y no una herramienta online?

Tres de las herramientas AES online más visitadas — aesencryption.net, encryption-decryption.online, devglan.com — aceptan su texto claro y su passphrase y los envían por POST HTTPS a un servidor. El servidor cifra y devuelve el ciphertext. Es absurdo: un cifrado cuyo propósito es mantener secreto el texto claro lo filtra a un servidor remoto antes incluso de calcular. HTTPS protege la conexión, no al operador del servidor, no los logs del proveedor cloud, no a un atacante con acceso al servidor.

El AES en el navegador le da la vuelta. Su texto claro y su passphrase permanecen en el contexto JavaScript de la pestaña del navegador. Son procesados por la API crypto.subtle, que se ejecuta dentro del motor del navegador — el mismo camino de código que el navegador utiliza para los handshakes TLS. El ciphertext aparece en la pestaña. Usted lo copia, lo comparte, el texto claro nunca viaja.

¿Por qué estos tres algoritmos, ni más ni menos?

AES-256-GCM es el predeterminado y la recomendación. AES (Advanced Encryption Standard) fue certificado por el NIST en 2001 (FIPS 197) y sigue intacto — no se conoce ningún método práctico que reduzca la fortaleza efectiva de la clave por debajo del límite de la fuerza bruta. Con una clave de 256 bits, sigue siendo cómodo incluso frente al algoritmo cuántico de Grover, que solo reduciría la fortaleza efectiva a 128 bits — todavía sólidos. GCM (Galois/Counter Mode) añade una etiqueta de autenticación — cualquier manipulación del ciphertext se detecta al descifrar. Especificación: NIST SP 800-38D.

AES-128-GCM es la variante más rápida con clave de 128 bits. Sigue siendo sólido; sensato cuando importa la velocidad bruta en hardware antiguo o en contextos embebidos. Para la mayoría de los casos de uso en navegador, la diferencia de velocidad es insignificante.

AES-256-CBC es el modo clásico sin etiqueta de autenticación. El relleno PKCS#7 permite cifrar cualquier longitud de texto claro. Advertencia importante mostrada por la herramienta: CBC NO detecta la alteración del ciphertext. Un solo bit cambiado descifra a datos inservibles sin lanzar error — peligroso cuando los datos se consumen sin checksum separado. Ofrecemos CBC solo porque muchos sistemas heredados (aplicaciones Java antiguas, ciertos firmwares IoT) únicamente soportan CBC. Para datos nuevos: prefiera GCM.

Lo que deliberadamente no ofrecemos: AES-ECB (Electronic Codebook). ECB está criptográficamente roto porque bloques idénticos de texto claro producen ciphertext idéntico, exponiendo los patrones del texto claro — la famosa demo del pingüino ECB lo evidencia: una imagen de Tux cifrada en ECB sigue mostrando la silueta del pingüino. Muchas herramientas online listan ECB como opción, algunas como predeterminado. Nosotros lo bloqueamos en duro.

¿Cómo funciona PBKDF2 y por qué lo necesito?

Una passphrase no es una clave. Una passphrase típica tiene 20–40 bits de entropía; AES quiere 128 o 256. Cerrar esa brecha es el trabajo de una función de derivación de clave (KDF) — estira la passphrase hasta la longitud completa de clave y encarece los intentos de fuerza bruta mediante muchas operaciones de hash repetidas.

Usamos PBKDF2 con SHA-256 como función hash y 100.000 iteraciones. Esto se corresponde con la recomendación mínima de OWASP 2024 para PBKDF2-HMAC-SHA-256. Cada cifrado genera una sal aleatoria fresca de 16 bytes, que se guarda junto al ciphertext. La sal impide los ataques por tabla arcoíris: dos usuarios con la misma passphrase terminan con claves distintas.

Hay KDF más modernas — Argon2 (ganador de la Password Hashing Competition 2015), scrypt (memory-hard) — que resisten aún mejor a la fuerza bruta en GPU. La Web Crypto API del navegador todavía no soporta Argon2 de forma nativa; requeriría WebAssembly, lo que rompería nuestro compromiso de cero dependencias. PBKDF2 con 100.000 iteraciones SHA-256 es suficiente para el uso educativo.

¿Qué contiene realmente el blob de salida?

La salida del ciphertext es una concatenación de tres componentes, codificados en Base64 o Hex:

[sal:16 bytes][IV:12 bytes para GCM, 16 bytes para CBC][ciphertext (+ tag auth 16 bytes para GCM):variable]

Al descifrar, la herramienta lee los primeros 16 bytes como sal, los siguientes 12 (o 16 para CBC) como IV, y trata el resto como ciphertext + tag de autenticación opcional. Esta convención de disposición no está estandarizada por el NIST — distintas herramientas AES usan distintos órdenes. La documentamos explícitamente para que pueda construir la interoperabilidad usted mismo.

Descifrado externo con Python (biblioteca cryptography):

import base64
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.kdf.pbkdf2 import PBKDF2HMAC
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

blob = base64.b64decode("SU_SALIDA_BASE64")
salt, iv, ct = blob[:16], blob[16:28], blob[28:]
kdf = PBKDF2HMAC(algorithm=hashes.SHA256(), length=32, salt=salt, iterations=100000)
key = kdf.derive(b"SU_PASSPHRASE")
plaintext = AESGCM(key).decrypt(iv, ct, None)
print(plaintext.decode("utf-8"))

OpenSSL CLI no cubre directamente esta disposición vía openssl enc porque OpenSSL usa su propio prefijo de sal. Para una compatibilidad OpenSSL pura, habría que extraer sal e IV manualmente y llamar a openssl enc -K <hex> -iv <hex> — tedioso. Python o Node son los caminos ergonómicos.

¿Cuán segura es realmente la passphrase?

La seguridad de todo el cifrado descansa sobre la passphrase. AES-256 no puede romperse matemáticamente — pero si la passphrase es «Secret123», una GPU la rompe en horas, sin importar la fortaleza del cifrado.

Reglas prácticas para 2026:

• Menos de 8 caracteres, una sola clase (solo minúsculas): inseguro; fuerza bruta en segundos a minutos.
• 8 a 11 caracteres, clases mezcladas: horas a días contra una GPU moderna con 100.000 iteraciones PBKDF2.
• 12 a 15 caracteres, clases mezcladas: semanas a meses. Aceptable para casos de uso de baja amenaza.
• 16+ caracteres, clases mezcladas o patrón Diceware: años a décadas. Recomendado.
• Diceware con 6 palabras de una lista de 7.776 palabras: ~77 bits de entropía, prácticamente irrompible por fuerza bruta hasta los años 2050 y más allá.

El indicador de fortaleza bajo el campo passphrase es una heurística aproximada (longitud + mezcla de clases), no un estimador a nivel zxcvbn. Marca en rojo las entradas claramente débiles, en amarillo los casos límite y en verde a partir de una longitud sólida.

Lo que esta herramienta deliberadamente no hace

Cifrar archivos. El MVP solo acepta texto. El cifrado masivo de archivos está en el backlog de la Fase-2 — requiere lectura chunked + UI de progreso + manejo de blob descargable. Solución hoy: codificar archivos pequeños en Base64 (built-in del navegador o nuestro Base64 Encoder) y cifrar la cadena Base64.

Criptografía asimétrica. Esa clase (RSA, curvas elípticas, PGP, age) tiene una UX fundamentalmente distinta: una clave pública y una privada, gestión de claves, un modelo de confianza. Herramienta separada si llegara a hacer falta, no metida a la fuerza en la herramienta AES.

Almacenamiento de claves en la nube. Anti-caso-de-uso. Un cifrado cuya clave vive en el servidor de otro es una base de datos en la nube con pasos adicionales.

Sal personalizada o IV personalizado. Foot-gun. Los usuarios fijarían IV estáticos y destruirían la garantía de seguridad. Deliberadamente no expuesto.

Argon2 o scrypt como alternativas KDF. PBKDF2 es nativo a Web Crypto. Argon2 requeriría WebAssembly (libsodium) y aumentaría el bundle. Evaluar solo cuando los modelos de amenaza realmente lo exijan.

Uso educativo — ¿qué significa eso en la práctica?

Esta herramienta está construida para uso educativo y personal habitual: mantener en secreto una nota corta, compartir un punto de encuentro en un chat, cifrar una frase de API en un cuaderno personal, ponerse a tocar el concepto AES de primera mano. No está construida para:

• Cifrado de datos personales exigido por el RGPD / HIPAA en contextos empresariales — para ello hacen falta tokens hardware certificados, firmas cualificadas, gestión documentada de claves con rotación y estrategia de backup.
• Defensa contra actores estatales o servicios de inteligencia — esos modelos de amenaza requieren módulos de seguridad hardware (HSM), secure enclaves, máquinas air-gapped, forward secrecy a nivel de protocolo.
• Cifrado de cumplimiento médico, financiero o legal — véase los requisitos de HIPAA, PCI-DSS, eIDAS.

Para esos casos de uso, las herramientas adecuadas son GnuPG (para cifrado fichero/correo con web-of-trust), age (moderno, más esbelto), HashiCorp Vault o equivalentes a AWS-KMS (para gestión de claves server-side) o servicios de firma cualificada bajo eIDAS.

Uso educativo significa: la herramienta es matemáticamente correcta, usa primitivas validadas FIPS, la salida es interoperable con stacks criptográficos profesionales. Pero las hipótesis del modelo de amenaza — passphrase en la cabeza, sin HSM, sin audit log, sin workflow de rotación de claves — solo encajan en contextos de baja amenaza.

¿Cómo se comporta la Web Crypto API entre versiones de navegador?

Estable y cross-browser desde aproximadamente 2017. En concreto:

• Chrome / Edge: desde la versión 37 (2014).
• Firefox: desde la versión 34 (2014).
• Safari (macOS / iOS): desde Safari 11 / iOS 11 (2017).

Los métodos aquí utilizados (crypto.subtle.encrypt, crypto.subtle.decrypt, crypto.subtle.deriveKey, crypto.subtle.importKey, crypto.getRandomValues) están todos especificados en la W3C Web Cryptography API Recommendation (2017) e implementados por completo en todos los navegadores principales. En Safari móvil iOS 11+ y Chrome Mobile rige lo mismo. Sin polyfill, sin fallback.

¿Cómo verificar que el cifrado realmente se ejecuta localmente?

Abra la pestaña Red de las DevTools (Cmd+Option+I en Mac, F12 en Windows), ejecute un cifrado — no se dispara ninguna petición de red. El service worker instala el caché PWA, así la página carga sin conexión y AES sigue funcionando. El código fuente del componente es inspectable en el navegador (pestaña Sources → AesVerschluesselungTool.svelte) — las llamadas cripto son directamente rastreables.

Un segundo control de coherencia: en la consola de DevTools, escriba crypto.subtle — debería ver un objeto SubtleCrypto. Los métodos de ese objeto están implementados en el propio motor del navegador (C++ en Chrome/Edge, en Rust + C++ en Firefox, en Swift/C++ en WebKit), no en JavaScript cargado desde una CDN. Cuando esta herramienta llama a crypto.subtle.encrypt(...), el control pasa directamente a esos métodos nativos. El texto claro nunca atraviesa un fetch(), nunca aterriza en un cuerpo de petición, nunca se serializa hacia un servidor en algún sitio.

¿Por qué cada cifrado produce un ciphertext distinto?

Cifre dos veces el mismo texto claro con la misma passphrase y las dos salidas son completamente distintas. Es deliberado e importante. Cada llamada genera una sal aleatoria fresca de 16 bytes (es decir, una clave derivada distinta) y un IV aleatorio fresco de 12 o 16 bytes. Sin esto, un atacante que observara dos ciphertexts podría detectar que los textos claros son idénticos — una fuga de metadatos que destruye la confidencialidad para mensajes repetidos.

La sal y el IV se guardan junto al ciphertext (en la cabecera del blob). No son secretos — las garantías de seguridad de AES-GCM se sostienen siempre que el IV sea único por cifrado bajo la misma clave, no siempre que el IV esté oculto. Reutilizar el mismo IV bajo la misma clave con GCM es una ruptura catastrófica: filtra el XOR de dos textos claros y permite la falsificación de la etiqueta de autenticación. El IV aleatorio por llamada en esta herramienta es la defensa más importante contra esa trampa peligrosa.

¿Qué pasa si manipulo el ciphertext?

Para AES-GCM (predeterminado), la herramienta lo detecta. El modo Galois/Counter añade una etiqueta de autenticación de 16 bytes a cada ciphertext. Al descifrar, la etiqueta se recalcula a partir del ciphertext + IV + clave y se compara. Si el ciphertext, el IV o la clave son erróneos en un solo bit, la etiqueta recalculada no coincide y la API lanza un OperationError — mostrado como «Decryption failed» en la UI. No puede obtener salida con forma de texto claro cambiando bits del ciphertext.

Para AES-CBC, la manipulación pasa desapercibida. Cambie un bit, descifre y obtendrá datos con forma de texto claro inservible para ese bloque más un cambio de bit explotable en el bloque siguiente (ataque de bit-flipping en CBC). Por eso existe GCM y por eso marcamos CBC como heredado. Si tiene que usar absolutamente CBC (interop con sistemas antiguos), combínelo con un HMAC separado sobre el ciphertext — pero a esas alturas está reconstruyendo Encrypt-then-MAC a mano y haría mejor en usar simplemente GCM.

¿Quién realmente necesita esto en el día a día?

• Desarrolladores y desarrolladoras que quieren compartir una frase de API, un punto de encuentro o un token de prueba en correo o DM de Slack sin montar antes un intercambio de claves PGP.
• Profesores y estudiantes en cursos de criptografía, para recorrer AES en la práctica: qué cambia cuando modifico la passphrase, cómo lucen las variaciones de IV, qué hace realmente el padding PKCS#7.
• Periodistas con contactos fuente de baja amenaza que quieren reenviar una nota corta desde un cuaderno de investigación por correo.
• Personas particulares con un cuaderno lleno de contraseñas que quieren respaldar el cuaderno en la nube, con el texto claro quedándose sin conexión y el ciphertext viajando a iCloud / Dropbox / Drive.

En cada caso: esta herramienta está un escalón por encima de «texto claro en la nube» y un escalón por debajo de «workflow GnuPG con HSM». Cubre un hueco que las herramientas online con ida y vuelta al servidor sencillamente no pueden cubrir.

Preguntas frecuentes

Las respuestas clave viven en el bloque FAQ de arriba — se emiten como JSON-LD FAQPage estructurado para los motores de búsqueda.

¿Qué herramientas están relacionadas?

Otras herramientas del ecosistema kittokit que encajan en el mismo contexto:

• Hash Generator — calcule hashes MD5 / SHA-1 / SHA-256 / SHA-384 / SHA-512 de texto, íntegramente en el navegador.
• Generador de contraseñas — genere passphrases aleatorias fuertes, perfectas para claves AES.
• JWT Decoder — decodifique JWTs sin ida y vuelta al servidor.