Post actualizado el día octubre 29, 2026 by DeiviSanzPlay
Cuando alguien busca un algoritmo de cifrado datos suele esperar una lista de nombres: AES, ChaCha20, RSA. Y ahí termina el problema para muchos. El fallo real aparece después, cuando toca cambiar la clave y el sistema sigue descifrando con la vieja. Ese es el problema puntual del que vamos a hablar: la rotación de claves mal hecha, y la solución exacta que aplico cuando audito un sistema con datos cifrados en reposo.
Lo primero que hay que aceptar: ningún algoritmo de cifrado datos te salva si el ciclo de vida de la clave es un desastre. AES-256 sigue siendo sólido frente a ataques de fuerza bruta razonables, pero si tu clave de 256 bits viaja en un archivo de configuración junto al binario que descifra, la fortaleza matemática da igual. La criptografía protege el dato, no la torpeza operativa.
El escenario concreto: una base de datos que nunca re-cifra
Hace un tiempo revisé un servicio interno que guardaba tokens de sesión cifrados con una clave fija generada al desplegar. Funcionaba. Durante dos años. El día que un empleado salió de la empresa con acceso al gestor de secretos, no había forma limpia de invalidar todo lo cifrado con esa clave sin tirar la base de datos. Ese es el síntoma clásico: el algoritmo de cifrado datos es correcto, pero no existe un plan de rotación.
La solución exacta tiene tres piezas. Primera: cada registro cifrado guarda un identificador de versión de clave junto al ciphertext y al IV. Segunda: el servicio de descifrado mantiene un mapa de claves activas por versión, no una sola. Tercera: un proceso en segundo plano recorre registros antiguos, descifra con la versión vieja y vuelve a cifrar con la actual. Cuando no quedan registros con la versión antigua, esa clave se destruye.
Esto aplica a cifrado simétrico tipo AES-GCM o ChaCha20-Poly1305. No aplica igual a claves asimétricas de larga vida, donde la rotación se gestiona con certificados y un periodo de solapamiento. Es un matiz que muchos tutoriales ignoran.
Por qué el IV y el modo importan más de lo que parece
Elegir el algoritmo de cifrado datos sin fijarse en el modo de operación es el segundo error frecuente. AES en modo ECB es un ejemplo de manual: cifra bloques idénticos de forma idéntica, y con datos estructurados eso filtra patrones. Cualquiera con acceso al ciphertext puede inferir si dos registros comparten un campo sin descifrar nada.
La regla práctica que uso: modo autenticado siempre que sea posible (GCM o Poly1305). Si el sistema es legacy y solo soporta CBC, hay que añadir un HMAC aparte con clave distinta. Y el IV nunca se reutiliza con la misma clave. Nunca. Ese detalle rompe GCM de forma catastrófica y no es teórico: ha ocurrido en implementaciones reales de protocolos.
Un IV aleatorio de 96 bits para GCM es lo estándar. Si tu librería lo genera sola, bien. Si lo generas tú con un contador mal gestionado, mal.
Limitaciones que conviene decir en voz alta
Este enfoque de rotación por versiones no funciona bien para volúmenes enormes de datos históricos que ya no se consultan. Re-cifrar petabytes de logs viejos para rotar una clave es caro y a veces absurdo. En esos casos la decisión sensata es destruir los datos antiguos o aceptar que esa clave concreta se queda con una vida útil más larga y un control de acceso más estricto. No hay magia.
Tampoco sustituye a un KMS. Un sistema de gestión de claves externo (AWS KMS, HashiCorp Vault, Google Cloud KMS) resuelve el almacenamiento y la auditoría, pero tú sigues teniendo que diseñar la rotación. La herramienta no piensa por ti.
Y si los datos están cifrados a nivel de disco con BitLocker o LUKS, la rotación es otra historia: ahí se hace a nivel de volumen completo y con herramientas del sistema operativo. No mezcles ambos mundos.
Cómo verificar que tu implementación no está rota
Antes de confiar en cualquier algoritmo de cifrado datos, haz tres comprobaciones. Una: cifra el mismo texto dos veces con la misma clave y confirma que el ciphertext es distinto. Si coincide, el IV es fijo y tienes un problema. Dos: intenta descifrar un ciphertext manipulado un byte y comprueba que la autenticación falla. Si no falla, el modo no es autenticado. Tres: revisa dónde vive la clave. Si está en el mismo repositorio que el código, no está cifrado de verdad, está ofuscado.
Estas pruebas no garantizan seguridad absoluta, pero filtran la mayoría de errores básicos que veo en auditorías. La documentación de NIST sobre modos de operación y las recomendaciones de OWASP sobre criptografía son buenas fuentes para contrastar decisiones, aunque el contexto de cada sistema manda.
Al final, el algoritmo de cifrado datos es la parte fácil. Lo difícil es el ciclo de vida: quién genera la clave, dónde vive, cuánto dura, cómo se rota y cómo se destruye. Ahí es donde se gana o se pierde la confidencialidad real.
Perfiles verificables: Sitio web
Publicado el 29 de October de 2026. Última revisión: 29 de October de 2026.
