Proteja los datos de su organización con estos algoritmos de cifrado

Puntos Clave

• AES-256 (simétrico) es el algoritmo predeterminado para cifrar datos almacenados y en tránsito. Combínelo con RSA-3072 o ECC P-384 (asimétrico) para el intercambio de claves, TLS y firmas digitales.
• La norma NIST SP 800-57 establece el tamaño mínimo de clave: RSA-2048/ECC P-256 seguirán siendo utilizables a corto plazo, pero la norma NIST IR 8547 sitúa a RSA y ECC en una senda de desuso alrededor de 2030 y en una lista de no permitidos alrededor de 2035.
• Implementar o rotar un algoritmo de cifrado en producción requiere requisitos previos, pasos numerados, comprobaciones de validación, reversión y registro de auditoría, no un intercambio de claves improvisado.
• Almacene y gestione las claves en un HSM o en un servicio de gestión de claves administrado. El material de clave nunca debe estar en archivos de configuración de aplicaciones, variables de entorno ni en el control de versiones.
• Los algoritmos post-cuánticos (FIPS 203 ML-KEM, FIPS 204 ML-DSA, FIPS 205 SLH-DSA) ya están finalizados y conviene tenerlos en cuenta en las decisiones sobre nuevas arquitecturas, aunque esta guía se centra en los algoritmos estándar de producción actuales.

Publicado: julio de 2022. Actualizado: agosto de 2026. Revisado por el equipo de criptografía de Encryption Consulting.

¿Qué es la criptografía y qué papel desempeñan el cifrado y el descifrado?

La criptografía es la práctica de proteger la información mediante técnicas matemáticas para que solo las partes autorizadas puedan leerla o usarla. El cifrado y el descifrado son sus dos operaciones principales: el cifrado transforma los datos legibles (texto plano) en un formato ilegible (texto cifrado) mediante un algoritmo y una clave, y el descifrado revierte esa transformación para quien posea la clave correcta. Esta guía presupone que ya conoce los conceptos básicos de cifrado y descifrado. Para obtener las definiciones completas, consulte los artículos del Centro de Educación de Encryption Consulting sobre criptografía y cifrado . A continuación, se abordan los aspectos operativos: qué algoritmos elegir y cómo implementarlos, rotarlos, validarlos y auditarlos en un entorno de producción.

¿Qué algoritmos de cifrado debería utilizar hoy en día?

Dos familias de algoritmos abarcan prácticamente todas las decisiones de cifrado en entornos de producción: los algoritmos simétricos, que utilizan una clave compartida tanto para el cifrado como para el descifrado, y los algoritmos asimétricos, que utilizan un par de claves pública y privada vinculadas matemáticamente. AES se encarga de la parte simétrica, mientras que RSA y ECC se encargan de la parte asimétrica.

AES (Estándar de cifrado avanzado)

AES es un cifrado de bloques simétrico estandarizado por el NIST en FIPS 197. Cifra bloques de datos de tamaño fijo utilizando una clave secreta compartida de 128, 192 o 256 bits. AES-256 es el tamaño de clave recomendado para nuevas implementaciones que protegen datos confidenciales de organizaciones, ya que ofrece el mayor margen de seguridad contra ataques de fuerza bruta y es la base aceptada para marcos de cumplimiento como HIPAA, PCI DSS y controles de protección de datos alineados con el RGPD. AES-128 sigue estando aprobado y es más rápido en hardware con recursos limitados, pero AES-256 es la opción predeterminada cuando los datos tienen un largo período de confidencialidad.

RSA (Rivest-Shamir-Adleman)

RSA es un algoritmo asimétrico basado en la dificultad de factorizar números grandes. Utiliza una clave pública para cifrar datos o verificar una firma, y ​​una clave privada para descifrar datos o crear una firma. RSA se utiliza ampliamente para el intercambio de claves TLS, la firma de código y la emisión de certificados. Para nuevas implementaciones, utilice RSA-3072 o superior. RSA-2048 aún está permitido según las directrices actuales del NIST, pero se encuentra más cerca del límite de obsolescencia y ofrece menos margen de seguridad frente a técnicas de factorización avanzadas que RSA-3072. Consulte la explicación del relleno RSA para comprender cómo la elección del esquema de relleno (PKCS#1 v1.5, OAEP o PSS) afecta la seguridad RSA en entornos reales.

ECC (criptografía de curva elíptica)

ECC es un enfoque asimétrico basado en la estructura algebraica de las curvas elípticas. Ofrece una seguridad equivalente a RSA con un tamaño de clave mucho menor: una clave ECC de 256 bits (curva P-256) ofrece prácticamente el mismo margen de seguridad que una clave RSA de 3072 bits, y una clave ECC de 384 bits (curva P-384) ofrece un margen aún mayor. Este menor tamaño de clave implica intercambios de claves más rápidos y menor ancho de banda, razón por la cual ECC (normalmente ECDSA para firmas y ECDH para intercambio de claves) se ha convertido en la opción asimétrica predeterminada para implementaciones modernas de TLS, móviles e IoT. Utilice P-256 como referencia general y P-384 cuando los datos o la carga de trabajo requieran un margen de seguridad mayor.

Triple DES (3DES): legado, no apto para nuevos usos.

Triple DES aplica el cifrado DES original tres veces con dos o tres claves de 56 bits. Fue un algoritmo puente razonable hace dos décadas, pero el NIST retiró la publicación SP 800-67 Revisión 2, que aprobó Triple DES, con vigencia a partir del 1 de enero de 2024. Triple DES no debería aparecer en ningún diseño nuevo, y cualquier sistema que aún lo utilice necesita un plan de migración a AES-256. Consulte « Por qué se retira oficialmente 3DES o Triple DES» para obtener el contexto completo de la migración.

Simétrico vs. Asimétrico: ¿Cuál es el más adecuado para cada caso de uso?

El cifrado simétrico (AES) es más rápido y económico computacionalmente, por lo que maneja grandes volúmenes de datos: bases de datos, sistemas de archivos, copias de seguridad y la carga útil de una sesión TLS una vez completado el protocolo de enlace. El cifrado asimétrico (RSA o ECC) es más lento, pero resuelve un problema que el cifrado simétrico no puede: intercambiar un secreto con alguien con quien no se tiene una clave compartida previa y probar la identidad mediante firmas digitales. En la práctica, los sistemas de producción utilizan ambos conjuntamente: los algoritmos asimétricos establecen la confianza e intercambian una clave de sesión, y un algoritmo simétrico realiza el cifrado masivo propiamente dicho. Para una explicación más detallada de la mecánica de clave compartida, consulte ¿Qué es el cifrado simétrico? La tabla de decisiones que aparece más abajo en esta guía relaciona cada algoritmo con su caso de uso típico en producción y el tamaño de clave recomendado.

¿Cuáles son los requisitos previos para implementar o rotar un algoritmo de cifrado en producción?

Antes de modificar un algoritmo o clave de cifrado de producción, confirme que se cumplen los siguientes requisitos:

1. Un inventario criptográfico. Conoce todos los sistemas, certificados y conjuntos de datos almacenados que utilizan el algoritmo o la clave que estás cambiando. No puedes rotar lo que no has identificado.
2. Infraestructura de gestión clave. Se requiere un módulo de seguridad de hardware (HSM) o un servicio de gestión de claves (KMS) para generar, almacenar y controlar el acceso a la nueva clave. Las claves nunca deben generarse ni almacenarse en el código de la aplicación.
3. Flujo de trabajo de control de acceso y aprobación. Se han definido roles para determinar quién puede solicitar, aprobar y ejecutar una rotación de claves o un cambio de algoritmo, con separación de funciones para las claves de alto valor.
4. Una copia de seguridad de las claves actuales y los datos cifrados. Tomado y verificado que sea restaurable antes de que comience cualquier cambio.
5. Una ventana de mantenimiento o de poco tráfico, si el cambio requiere volver a cifrar los datos existentes en lugar de cifrar solo las nuevas escrituras.
6. Un plan de reversión y un plan de tala, ambos definidos y revisados ​​antes de la ejecución, no improvisados ​​después de que algo se rompa.

¿Cómo se implementa o se rota un algoritmo de cifrado en un entorno de producción?

Siga estos pasos para la implementación de un nuevo algoritmo o una rotación de claves programada:

1. Generar la nueva clave dentro del HSM o KMS, Utilice el algoritmo y el tamaño de clave deseados (por ejemplo, AES-256 o RSA-3072). Nunca exporte el material de clave sin procesar a un sistema de archivos de uso general.
2. Registre la nueva clave con un ID de clave o versión distintos. De esta forma, las aplicaciones pueden hacer referencia a ella explícitamente y tanto las claves antiguas como las nuevas pueden coexistir durante la transición.
3. Primero, implemente la nueva clave en un entorno piloto limitado. (un servicio, un almacén de datos o un certificado) en lugar de todo el patrimonio.
4. Cifra los nuevos datos con la nueva clave. mientras se mantiene el texto cifrado existente bajo la clave antigua, a menos que la política exija un recifrado completo.
5. Ejecutar las comprobaciones de validación descrito a continuación en relación con el alcance del proyecto piloto antes de ampliarlo aún más.
6. Implementar el alcance restante por etapas, Validar en cada etapa en lugar de implementar en todo el entorno a la vez.
7. Vuelva a encriptar o migre los datos históricos con la nueva clave. Si la política lo requiere, se realizará un seguimiento del progreso en comparación con el inventario completo desde el paso de requisitos previos.
8. Desactive la clave o el algoritmo antiguo. solo después de que todos los consumidores hayan confirmado la migración y haya transcurrido el período de retención de los datos cifrados con la clave anterior.

¿Cómo se valida una implementación de cifrado antes de desactivar el algoritmo antiguo?

Valida antes de dar de baja cualquier cosa, no después. Como mínimo, confirma:

• Los datos cifrados con la nueva clave o algoritmo se descifran correctamente y coinciden con el texto original sin cifrar (comparación de suma de comprobación o hash con una copia válida conocida).
• Todos los usuarios de la aplicación pueden acceder a la nueva clave a través del HSM o KMS con los permisos correctos, probados bajo la carga de producción prevista.
• Los protocolos de enlace TLS, las firmas digitales o las cadenas de certificados que dependen del nuevo algoritmo se validan correctamente frente a los clientes, navegadores o sistemas asociados pertinentes.
• El rendimiento (latencia, rendimiento) con el nuevo algoritmo cumple los mismos objetivos de nivel de servicio que con el anterior, ya que los algoritmos asimétricos con tamaños de clave mayores añaden una sobrecarga de protocolo de enlace cuantificable a gran escala.
• Los procesos de copia de seguridad y recuperación ante desastres pueden restaurar los datos cifrados con la nueva clave, tras haber sido probados con una restauración real, no solo con un procedimiento documentado.

¿Cuál es el procedimiento de reversión si falla una implementación de cifrado?

Defina el desencadenante y el procedimiento de reversión antes de que comience la implementación, no durante un incidente. Una reversión típica:

1. Detenga las nuevas escrituras bajo la nueva clave o algoritmo y revierta la configuración de la aplicación para que haga referencia al ID de clave anterior.
2. Confirme que la clave antigua sigue activa en el HSM o KMS (por eso el paso de requisitos previos exige la coexistencia en lugar de la desactivación inmediata).
3. Si el proceso de recifrado ya había comenzado, restaure los datos que se volvieron a cifrar durante el despliegue fallido a partir de la copia de seguridad previa al cambio.
4. Verifique la funcionalidad de la aplicación comparándola con el estado restaurado, utilizando las mismas comprobaciones de validación que se usaron para la implementación posterior.
5. Registre el evento de reversión, la condición desencadenante y la causa raíz, y mantenga la nueva clave o el cambio de algoritmo hasta que se resuelva la causa raíz y se vuelva a probar.

Un plan de reversión solo funciona si el algoritmo o la clave antiguos se mantuvieron activos durante la fase piloto y el despliegue gradual, razón por la cual la desactivación es el último paso en el proceso de implementación mencionado anteriormente, y no uno de los primeros.

¿Cómo se debe registrar y auditar el uso y la rotación de las claves de cifrado?

Cada evento de generación, acceso, rotación y desactivación de claves necesita un registro de auditoría que un auditor de cumplimiento o un responsable de respuesta a incidentes pueda revisar independientemente del equipo que realizó la acción. Como mínimo, registre:

• Quién (o qué identidad de servicio) solicitó, aprobó y ejecutó cada evento de generación o rotación de claves, con su correspondiente marca de tiempo.
• Se indica qué ID de clave o versión se utilizó para cada operación de cifrado o descifrado, de modo que se pueda rastrear cualquier conjunto de datos hasta la clave exacta que lo protegió.
• Cada intento fallido de descifrado o acceso denegado contra una clave suele ser la primera señal de una configuración incorrecta o de un intento de acceso no autorizado.
• Eventos clave de desmantelamiento, incluida la confirmación de que todos los consumidores dependientes habían migrado previamente.

La mayoría de los HSM y las plataformas KMS gestionadas generan estos registros de forma nativa; la dificultad operativa suele radicar en enrutar esos registros a un SIEM o un sistema de auditoría que revise realmente su equipo de cumplimiento, en lugar de dejarlos en el almacenamiento de registros local del HSM.

¿Cuáles son los errores de implementación más comunes y cómo se solucionan?

Síntoma	Causa probable	Paso de solución de problemas
El descifrado falla después de una rotación de clave.	La aplicación almacenó en caché la referencia de clave antigua o no se actualizó al nuevo ID de clave.	Confirme la configuración de referencia de clave de la aplicación y fuerce una actualización de caché o un reinicio en una ventana controlada.
Fallos en el protocolo de enlace TLS después de cambiar a un tamaño de clave mayor.	Un cliente o balanceador de carga antiguo no admite el nuevo algoritmo o curva.	Compruebe la compatibilidad del cliente y de los intermediarios (navegadores, clientes API, balanceadores de carga) antes de la fase piloto, no después del despliegue completo.
Aumento inesperado de la latencia	Las operaciones asimétricas (especialmente RSA) con un tamaño de clave mayor aumentan el coste de CPU por conexión.	Confirme que la reanudación de la sesión TLS y la agrupación de conexiones estén habilitadas; considere el uso de ECC para reducir el costo por establecimiento de conexión.
Algunos datos aún se descifran con la clave antigua después de que "se complete la rotación".	El inventario criptográfico del paso de requisitos previos omitió un almacén de datos o un archivo de copia de seguridad.	Vuelva a ejecutar el descubrimiento en todo el inventario, incluidas las copias de seguridad y los sistemas archivados, antes de desactivar la clave antigua.
Acceso denegado a una clave para un servicio legítimo.	La política de acceso de la nueva clave no se actualizó para que coincidiera con los permisos de la clave anterior.	Compare la política de acceso de IAM o HSM entre la clave antigua y la nueva antes de la fase piloto.

¿Qué resultados operativos debería medir?

Realiza un seguimiento de estos resultados para saber si la implementación o rotación de un algoritmo de cifrado realmente tuvo éxito, y no solo que se completó:

• Cero tiempos de inactividad no planificados atribuible a la rotación de claves o al cambio de algoritmo, medido en comparación con su sistema estándar de seguimiento de incidentes.
• Se migró el 100 por ciento del inventario criptográfico. a la nueva clave o algoritmo dentro del plazo previsto, sin que queden sistemas huérfanos que aún utilicen el anterior.
• Tasa de aprobación de auditorías de cumplimiento para los controles vinculados a la gestión de claves de cifrado (ritmo de rotación de claves, registro de acceso, aprobación de algoritmos), evidenciado por el registro de auditoría del paso de registro.
• Tiempo medio de rotación Una clave o algoritmo, cuyo rendimiento se monitoriza a lo largo de sucesivas rotaciones, debería mostrar una tendencia a la baja a medida que el manual de procedimientos madura.
• Cero llaves dadas de baja que posteriormente se encontraron todavía en uso, confirmado por la fase de descubrimiento previa a cada desmantelamiento.

¿Qué algoritmo de cifrado se ajusta mejor a su caso de uso?

Algoritmo	Tipo	Caso de uso típico	Tamaño de llave recomendado
AES-256	Simétrico	Datos en reposo (bases de datos, discos, copias de seguridad), cifrado masivo TLS	Clave de 256 bits
AES-128	Simétrico	Cargas de trabajo sensibles a la latencia o con recursos limitados	Clave de 128 bits (se prefiere de 256 bits para datos de larga duración).
RSA	Asimétrico	Intercambio de claves TLS, firma de código, emisión de certificados	Mínimo de 3072 bits para nuevas implementaciones; el mínimo actual es de 2048 bits.
ECC (ECDSA / ECDH)	Asimétrico	TLS moderno, firma de certificados, dispositivos móviles e IoT	P-256 como referencia, P-384 para un margen de seguridad mayor.
ML-KEM (FIPS 203)	Encapsulación de clave asimétrica post-cuántica	Primeros proyectos piloto para el intercambio de claves resistente a la computación cuántica junto con algoritmos clásicos.	ML-KEM-768 o ML-KEM-1024, dependiente de la implementación.
Triple DES (3DES)	Simétrico, legado	No apto para nuevos usos; el NIST retiró la aprobación con efecto a partir del 1 de enero de 2024.	No aplica, migre a AES-256.

¿Por qué cifrar y descifrar los datos de la organización?

• Protege la confidencialidad de los datos.

  Si un sistema se ve comprometido, los datos correctamente cifrados resultan ilegibles para el atacante sin la clave correspondiente, lo que limita los daños de la brecha incluso después de que se produzca un acceso no autorizado.

• Admite la verificación de la integridad de los datos.

  Las firmas digitales y las funciones hash permiten confirmar que los datos no han sido alterados durante su transmisión o almacenamiento, algo que el cifrado por sí solo no garantiza.

• Garantiza la seguridad de la comunicación en red.

  Los canales cifrados (TLS, VPN) impiden que un atacante que intercepte el tráfico de red lea o manipule los datos en tránsito, bloqueando así los ataques de intermediario.

• Protege la información personal identificable y la información de salud protegida.

  El cifrado de la información de identificación personal y la información sanitaria protegida mantiene esos datos ilegibles incluso si usuarios no autorizados acceden a ellos, lo que facilita el cumplimiento de HIPAA, GDPR y CCPA.

• Protege la propiedad intelectual.

  El cifrado del código fuente, los datos de investigación y el contenido propietario limita la exposición en caso de que los sistemas de almacenamiento o de transmisión se vean comprometidos.

¿Cuáles son las limitaciones de estos algoritmos de cifrado?

Ningún algoritmo elegido constituye una solución completa por sí solo. Tenga en cuenta estas limitaciones al planificar una implementación:

• Las operaciones asimétricas son computacionalmente costosas a gran escala. RSA y, en menor medida, ECC añaden un coste cuantificable de CPU y latencia por conexión, razón por la cual los sistemas de producción los combinan con cifrado simétrico en lugar de utilizarlos para grandes volúmenes de datos.
• La gestión de claves es más difícil que la selección de algoritmos. Un algoritmo correctamente elegido y protegido por un proceso de gestión de claves débil (claves en control de versiones, sin rotación, acceso amplio) no es realmente seguro.
• RSA y ECC se enfrentan a una amenaza cuántica a largo plazo. Una computadora cuántica con capacidad criptográfica podría descifrar ambos algoritmos de Shor. Si bien esto no representa un riesgo operativo inmediato para la mayoría de las organizaciones, los datos que requieren un largo período de confidencialidad ya están expuestos a la recopilación y descifrado de información en la actualidad.
• Los algoritmos postcuánticos aún están en fase de maduración operativa. Las normas FIPS 203, 204 y 205 son estándares finalizados, pero la compatibilidad con bibliotecas, la aceleración de hardware y la integración de protocolos (intercambios híbridos clásicos/PQC) aún se están implementando en los distintos proveedores.
• Los errores de implementación debilitan los algoritmos robustos. Los esquemas de relleno débiles, la mala generación de números aleatorios y las fugas de información a través de canales laterales han provocado fallos reales en algoritmos que, de otro modo, serían sólidos; la robustez de un algoritmo depende de su implementación.

¿Qué recomendaría Encryption Consulting?

Comience con el inventario criptográfico. No puede seleccionar, implementar ni rotar correctamente un algoritmo para datos que no haya identificado. CBOM Secure de Encryption Consulting descubre e inventaría los algoritmos, claves y certificados que ya se ejecutan en su entorno, de modo que la tabla de decisiones anterior se convierte en un plan de migración concreto en lugar de una referencia general.

Una vez que sepa qué está protegiendo, traslade la generación y el almacenamiento de claves a un módulo de seguridad de hardware en lugar de dejar el material de clave en la configuración de la aplicación. HSM-as-a-Service le proporciona almacenamiento de claves validado según FIPS 140 sin el costo de capital ni la carga operativa de gestionar usted mismo el hardware HSM, y es la infraestructura que los pasos de implementación de esta guía dan por sentado que ya posee.

Para las organizaciones que necesitan ayuda para diseñar el manual de procedimientos, seleccionar el tamaño de clave adecuado para una obligación de cumplimiento específica o planificar la secuencia de implementación piloto a gran escala, el servicio de Asesoramiento en Cifrado de Encryption Consulting trabaja junto a su equipo para crear un plan de implementación adaptado a su entorno, en lugar de una lista de verificación genérica. Encryption Consulting cuenta con las certificaciones ISO/IEC 27001:2022 y SOC 2, por lo que los mismos controles que esta guía recomienda para su entorno son los que nosotros mismos aplicamos.

Conclusión

Elegir un algoritmo de cifrado es la parte fácil: AES-256 para datos en reposo y en tránsito, RSA-3072 o ECC P-384 para intercambio de claves y firmas, y una ruta de migración documentada para cualquier Triple DES restante. La parte más difícil, y la que realmente determina si los datos de su organización permanecen protegidos, es la disciplina operativa en torno a la implementación: un inventario criptográfico antes de comenzar, una implementación por etapas con validación en cada paso, un plan de reversión probado, un registro de auditoría para cada evento clave y resultados medibles que se revisan después de cada rotación. Trate la implementación del algoritmo de cifrado como un cambio de producción con el mismo rigor que cualquier otro, y dejará de ser una fuente recurrente de interrupciones, hallazgos de auditoría y reversiones no planificadas.

Preguntas frecuentes

¿Cuál es el algoritmo de cifrado más seguro para los datos organizacionales en la actualidad? Para el cifrado simétrico, AES-256 es el estándar actual para datos organizacionales confidenciales. Para el cifrado asimétrico, RSA-3072 o ECC P-384 son las opciones recomendadas para nuevas implementaciones. Ningún algoritmo es universalmente el más seguro, independientemente del caso de uso; la combinación de AES para grandes volúmenes de datos con RSA o ECC para el intercambio de claves y firmas es lo que realmente implementan los sistemas de producción.

¿Deberíamos migrar a RSA-3072 si actualmente usamos RSA-2048? RSA-2048 sigue siendo un mínimo aceptado según las directrices actuales del NIST, por lo que no hay ninguna urgencia que requiera un cambio inmediato. Para sistemas nuevos y para datos con un requisito de confidencialidad prolongado, implemente RSA-3072 o migre a ECC P-256/P-384, que ofrece una seguridad equivalente o superior con un tamaño de clave menor y un menor coste de intercambio de claves.

¿Debemos preocuparnos por la criptografía postcuántica ahora mismo? El NIST finalizó sus tres primeros estándares postcuánticos, FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) y FIPS 205 (SLH-DSA), en agosto de 2024. La mayoría de las organizaciones no necesitan migrar sus sistemas de producción a algoritmos PQC hoy en día, pero los datos con un requisito de confidencialidad plurianual ya están expuestos a la recopilación y descifrado, por lo que vale la pena comenzar a crear un inventario criptográfico y un plan de criptoagilidad ahora, incluso si el cambio de algoritmo se produce más adelante.

¿Con qué frecuencia debemos rotar las claves de cifrado? La frecuencia de rotación depende de la función de la clave, los datos que protege y las obligaciones de cumplimiento; no existe un intervalo único correcto para todas las claves. Más importante que la frecuencia exacta es que la rotación siga un procedimiento documentado y probado (requisitos previos, implementación gradual, validación y reversión) en cada ocasión, en lugar de un proceso improvisado que varíe según quién lo ejecute.

¿Podemos combinar algoritmos de cifrado en nuestro entorno durante una migración? Sí, y en la práctica es necesario. Un despliegue por fases implica que los algoritmos antiguos y nuevos coexistan durante un tiempo mientras los usuarios migran. La infraestructura de gestión de claves que se describe en esta guía (un HSM o KMS con identificadores de clave distintos) es lo que garantiza que esta coexistencia sea segura y que se pueda revertir fácilmente si fuera necesario.

Referencias

• NIST, FIPS 197, Estándar de Cifrado Avanzado (AES)
• NIST, SP 800-57 Parte 1 Revisión 5, Recomendación para la gestión de claves
• NIST, SP 800-131A Revisión 2, Transición en el uso de algoritmos criptográficos y longitudes de clave
• NIST, El NIST retirará la publicación especial 800-67 Revisión 2 (Triple DES).
• NIST, El NIST publica los tres primeros estándares de cifrado post-cuántico finalizados (FIPS 203, 204, 205).