Qué es AES-256-GCM y por qué importa en las apps de notas

AES-256-GCM es el cifrado autenticado de TLS 1.3, IPsec y 1Password: qué significa su nombre, por qué GCM supera a CBC y qué pedir a una app de notas.

Mathis Belouar-Pruvot

· fundador de Filarr · · 10 min de lectura

Respuesta rápida. AES-256-GCM es un modo de cifrado autenticado que combina AES-256 (el cifrado simétrico que usan gobiernos, bancos y Signal) con GCM (Galois/Counter Mode, que añade la detección de manipulaciones). Es el modo que usan TLS 1.3, IPsec y 1Password. Una app de notas que presume de «cifrado AES-256» debería precisar GCM (u otro modo autenticado): AES-256-CBC a secas, sin autenticación, es una señal de alarma.

Cuando una app centrada en la privacidad dice «tus datos están protegidos con cifrado AES-256», la frase está incompleta. AES-256 es un algoritmo de cifrado, no un esquema de cifrado completo. El modo de operación importa tanto como el algoritmo en sí, y un modo mal elegido puede dejar AES-256 prácticamente inservible.

Este artículo desmonta AES-256-GCM en lenguaje claro: qué hace cada pieza, por qué supera a modos más antiguos como CBC, cuáles son sus trampas conocidas y qué debes comprobar cuando una app de notas o de almacenamiento de archivos dice usarlo.

¿Qué significa AES-256-GCM, pieza a pieza?

El nombre tiene tres partes: AES, 256 y GCM. Cada una significa algo concreto.

AES (Advanced Encryption Standard) es un cifrado simétrico estandarizado en 2001 por el Instituto Nacional de Estándares y Tecnología de Estados Unidos (NIST) (FIPS 197). «Simétrico» significa que la misma clave cifra y descifra. AES es el cifrado más analizado del mundo y, en su versión completa, sigue sin romperse.

256 es la longitud de la clave en bits. AES está definido para tres longitudes de clave: 128, 192 y 256 bits. AES-256 es la variante más robusta, con un espacio de claves de 2²⁵⁶: astronómicamente mayor que lo que puede alcanzar en la práctica cualquier ataque de fuerza bruta, incluso con un hipotético hardware cuántico (el algoritmo de Grover divide por dos la longitud efectiva de la clave, lo que deja a AES-256 con una seguridad poscuántica de 2¹²⁸, que sigue siendo inalcanzable).

GCM (Galois/Counter Mode) es un modo de operación. AES, por sí solo, solo cifra un bloque de 128 bits. Para cifrar datos de cualquier longitud hace falta un modo que encadene los bloques. GCM es uno de esos modos y, sobre todo, ofrece cifrado autenticado con datos asociados (AEAD): no solo cifra tus datos, también produce una etiqueta que detecta cualquier manipulación.

En resumen, AES-256-GCM = «cifrar con AES, con una clave de 256 bits, en un modo que detecta las manipulaciones».

¿Por qué importa GCM? ¿AES no es ya seguro?

AES es seguro como cifrado de bloque. Pero un cifrado de bloque no sirve de nada por sí solo: necesitas un modo de operación, y la elección del modo determina las propiedades de seguridad de todo el sistema.

El error clásico es usar AES en modo CBC sin autenticación. CBC cifra bien tus datos, pero no te avisa si alguien ha manipulado el texto cifrado. Un atacante capaz de invertir bits en el bloque cifrado puede alterar tu texto en claro de forma predecible, y esa misma falta de autenticación abre la puerta a la familia de ataques llamados «padding oracle» (véanse los ataques contra CBC en TLS, como BEAST y Lucky 13). El descifrado funciona, pero lo que recuperas es un texto en claro manipulado.

GCM lo resuelve calculando una etiqueta Galois MAC (GMAC) junto al texto cifrado. Al descifrar, si la etiqueta no coincide, el descifrado falla: nunca ves un texto en claro manipulado. Esto es el cifrado autenticado y, en 2026, es la única opción aceptable para un sistema nuevo.

Modo¿Cifra?¿Detecta manipulaciones?Estado
AES-ECBSí (mal)NoRoto: no usar nunca
AES-CBC (sin MAC)SíNoEvitar
AES-CBC + HMACSíSí (si se combinan bien)Válido, pero propenso a errores
AES-GCMSíSí (integrado)Recomendado
AES-OCBSíSí (integrado)Históricamente sujeto a patentes
ChaCha20-Poly1305Sí (otro algoritmo)Sí (integrado)Alternativa igual de buena

¿Cómo funciona GCM por dentro?

GCM combina dos operaciones:

  1. Cifrado en modo contador (CTR). GCM toma un nonce de 96 bits («number used once», número de un solo uso), le concatena un contador de 32 bits, cifra ese bloque con AES y aplica un XOR del resultado con cada bloque de texto en claro. Así AES se convierte en un cifrado de flujo. Cada bloque usa un contador distinto, de modo que dos textos en claro idénticos producen textos cifrados distintos.

  2. MAC sobre un cuerpo de Galois. Al mismo tiempo que cifra, GCM calcula un hash polinómico en GF(2¹²⁸) sobre el texto cifrado y los posibles datos asociados (cabeceras, metadatos). El resultado es una etiqueta de autenticación de 128 bits que se añade al texto cifrado.

Para descifrar, GCM repite el cálculo GMAC, lo compara con la etiqueta recibida y solo continúa con el descifrado si coinciden. Un solo bit invertido en el texto cifrado = etiqueta que no coincide = el descifrado se niega a devolver el texto en claro.

El rendimiento es excelente: GCM se puede paralelizar (modo contador) y los procesadores modernos implementan en hardware tanto AES como la multiplicación en GF(2¹²⁸) (instrucciones Intel AES-NI y PCLMULQDQ). En un portátil de 2026, AES-256-GCM funciona a entre 5 y 10 GB/s.

¿Cuál es la trampa mortal de AES-GCM?

GCM tiene una regla crítica, y saltársela tiene consecuencias reales: nunca reutilices un nonce con la misma clave. El nonce de 96 bits debe ser único para cada cifrado realizado con una clave dada.

Si reutilizas un nonce, se vienen abajo a la vez la confidencialidad y la autenticidad de GCM. Un atacante que vea dos textos cifrados con el mismo par (clave, nonce) puede:

  • aplicarles un XOR para obtener el XOR de los dos textos en claro (conocer un fragmento de uno revela el otro);
  • recuperar la subclave de autenticación GMAC y, a partir de ahí, falsificar textos cifrados arbitrarios que se descifren en lo que él quiera.

Es lo que se conoce como el forbidden attack («ataque prohibido»), y es la razón por la que las implementaciones de GCM deben tener cuidado. El NIST SP 800-38D (el estándar de GCM) limita a 2³² el número de cifrados por clave cuando se usan nonces aleatorios; más allá, el riesgo de reutilización se vuelve inaceptable.

La reutilización de nonces ya ha tenido consecuencias reales: en algunas de las primeras implementaciones de Bluetooth, en WPA2 (el ataque KRACK) y en las primeras implementaciones de GCM dentro de TLS. Una implementación correcta usa o bien un contador determinista, o bien nonces aleatorios por mensaje con límites de renovación de claves documentados.

Al evaluar el cifrado de una app de notas, la pregunta correcta no es «¿usan AES-256-GCM?», sino «¿cómo generan los nonces y cada cuánto renuevan las claves?».

¿Por qué las apps de notas usan AES-256-GCM?

Para notas y archivos, AES-256-GCM es la elección correcta porque:

  • Está estandarizado. NIST SP 800-38D, usado en TLS 1.3 e IPsec.
  • Es rápido. Acelerado por hardware en todos los procesadores fabricados en la última década.
  • Detecta las manipulaciones. Si un servidor (o un atacante) modifica tu nota cifrada, el descifrado falla de inmediato. Nunca lees un texto en claro corrupto.
  • Está disponible en todas partes. Hay implementaciones en el módulo crypto de Node.js, en SubtleCrypto del navegador, en libsodium, OpenSSL, la biblioteca estándar de Go y el crate aes-gcm de Rust.

En una app de notas, el esquema habitual es este:

  1. La contraseña del usuario pasa por una función de derivación de claves lenta (PBKDF2 o Argon2id) que produce una clave maestra; consulta KEK y FEK explicadas.
  2. Cada nota (o cada archivo) recibe una clave de datos aleatoria y exclusiva de 256 bits.
  3. La clave de datos cifra la nota con AES-256-GCM, con un nonce nuevo, aleatorio o basado en un contador.
  4. La clave de datos, a su vez, se cifra («se envuelve») con la clave maestra, también con AES-256-GCM.

Esta arquitectura de claves por archivo hace que una sola clave de archivo comprometida solo exponga un archivo, no toda la bóveda. Filarr hace otra elección: tus archivos y tus notas se cifran con la clave de tu cuenta (FEK), con un valor aleatorio nuevo para cada archivo, y solo los archivos grandes importados en el escritorio y los bloques sincronizados derivan además una clave propia; consulta la arquitectura de seguridad de Filarr para ver los parámetros exactos.

Qué comprobar en una app de notas que promete «cifrado AES-256»

Cuando una app centrada en la privacidad anuncia cifrado AES-256, hazle estas preguntas:

  1. ¿Qué modo? Hace falta GCM u otro modo autenticado. CBC a secas, ECB o un «AES-256» sin modo son señales de alarma.
  2. ¿Cómo se deriva la clave? ¿Directamente de la contraseña del usuario? Eso está mal: las contraseñas tienen muy poca entropía. Tiene que haber una función de derivación de claves (PBKDF2, Argon2id, scrypt) con un número de iteraciones documentado.
  3. ¿Hay claves por archivo o una única clave global? Las claves por archivo (o por nota) limitan el radio de daño: comprometer una clave no lo expone todo.
  4. ¿Cómo se generan los nonces? ¿Contador determinista? ¿Aleatorios, y con cuántos bits? Un «usamos AES-GCM» sin disciplina con los nonces es frágil.
  5. ¿Dónde está documentado el cifrado? Una app seria publica su modelo de amenazas y el diseño de su cifrado. Si no lo encuentras, da por hecho que es criptografía de folleto.
  6. ¿Se puede auditar el código? Las implementaciones de código abierto permiten a los investigadores en seguridad verificar las afirmaciones. Un AES-256 de código cerrado es una promesa, no una prueba.

¿Cómo usa Filarr AES-256-GCM?

Filarr cifra cada archivo y cada nota con AES-256-GCM bajo la clave de tu cuenta. El proceso completo:

  • Tu contraseña se refuerza con PBKDF2-SHA-512 y 600 000 iteraciones (muy por encima de las 210 000 que recomienda OWASP para PBKDF2-SHA512) para producir una clave de cifrado de claves (Key Encryption Key, KEK).
  • Tu cuenta, o tu perfil local, tiene una única clave de cifrado de archivos (File Encryption Key, FEK) aleatoria de 256 bits.
  • Cada archivo y cada nota se cifran con AES-256-GCM con la FEK, con un valor aleatorio (IV) nuevo para cada uno. Solo los archivos grandes importados en el escritorio y los bloques sincronizados derivan además una clave propia.
  • La FEK se cifra con la KEK, también con AES-256-GCM, y una segunda copia se envuelve con tu frase de recuperación.

Ni la KEK ni la FEK llegan nunca en claro a nuestros servidores. Si alguien robara el almacenamiento de nuestra sincronización en la nube, solo vería un flujo de bloques cifrados que no puede descifrar: nuestros servidores solo guardan tu clave envuelta. Sobre la contraseña de tu cuenta: desde el 16 de octubre de 2026, al iniciar sesión la app envía una clave derivada en tu dispositivo, no la contraseña. Durante una transición de unos dos meses, una cuenta que todavía no ha vuelto a iniciar sesión, o una versión antigua de la app, sigue enviando la contraseña (por HTTPS), y en ese caso un servidor comprometido podría captarla. Consulta el modelo de seguridad de Filarr para ver la arquitectura completa y el modelo de amenazas.

Para saber más

Artículos relacionados