Linux 7.3 estrena nuevas API de cifrado AES: el kernel prepara importantes mejoras de rendimiento y seguridad

Linux 7.3 llega con una mejora profunda en el subsistema criptográfico del kernel: nuevas API de biblioteca para los principales modos de cifrado AES usados internamente. No es una función visible como un nuevo escritorio o un controlador gráfico, pero puede impactar áreas críticas como almacenamiento cifrado, redes seguras, autenticación, Bluetooth, SMB, SEV y otros componentes que dependen de criptografía dentro del kernel.

El trabajo fue integrado durante el ciclo de Linux 7.3 y está liderado por Eric Biggers. Según el pull request de actualizaciones de la biblioteca criptográfica, se agregan API para modos AES usados en el kernel como ECB, CBC, CBC-CTS, CTR, XCTR, XTS, GCM y CCM. El objetivo es reemplazar usos difíciles e ineficientes de las API tradicionales crypto_skcipher y crypto_aead por interfaces de biblioteca más simples, documentadas y preparadas para futuras optimizaciones.

1. Qué cambia en Linux 7.3

Hasta ahora, muchos usuarios internos del kernel recurrían a las API tradicionales de criptografía para usar modos AES. Esas API son potentes, pero también complejas y menos eficientes para ciertos casos internos. Linux 7.3 introduce una capa de biblioteca específica para modos AES, de modo que los componentes del kernel puedan usar cifrado de forma más directa y con menos “pegamento” repetido.

Phoronix resume el cambio como la llegada de nuevas API de cifrado AES para la mayoría de modos usados dentro del kernel. También indica que este trabajo abrirá la puerta a más optimizaciones de rendimiento, menos duplicación de código y mejoras posteriores cuando el código optimizado por arquitectura se migre hacia la biblioteca común.

2. Por qué AES es tan importante para Linux

AES es uno de los algoritmos de cifrado simétrico más usados del mundo. En Linux aparece en muchas capas: discos cifrados con dm-crypt/LUKS, redes privadas, protocolos de autenticación, almacenamiento, sistemas de archivos, drivers, comunicaciones seguras, Bluetooth, SMB y mecanismos de protección de máquinas virtuales.

Por eso, cualquier mejora en la forma en que el kernel usa AES puede tener efectos acumulativos. No significa que todos los servidores serán automáticamente más rápidos al actualizar, pero sí que se está preparando una base más limpia para que futuras versiones aprovechen mejor instrucciones de hardware como AES-NI en x86, extensiones criptográficas en ARM64 y optimizaciones específicas por arquitectura.

3. El problema anterior: API potentes, pero difíciles e ineficientes

El pull request de Linux 7.3 explica que muchos usuarios internos de estos modos AES estaban usando crypto_skcipher o crypto_aead. Esas API existentes son descritas como difíciles de usar e ineficientes para estos casos; además, la falta de soporte adecuado en la biblioteca era considerada la principal brecha de la crypto library del kernel.

El nuevo diseño implementa API sobre el soporte existente de AES de bloque único, añade documentación completa, migra el antiguo uso de AES-GCM hacia una API más flexible y conecta las nuevas API con la crypto API tradicional mediante algoritmos crypto_skcipher y crypto_aead. Esto permite que las nuevas rutas también queden cubiertas por las pruebas internas de la crypto API.

4. Menos código duplicado y una biblioteca criptográfica más limpia

Uno de los objetivos principales es eliminar código “glue” repetido. El pull request señala que migrar el código AES optimizado por arquitectura desde arch/*/crypto/aes* hacia la biblioteca permitirá reducir duplicaciones. Además, los parches de prueba usados para diseñar la API mostraron una reducción neta de 1.905 líneas, lo que indica que las nuevas interfaces se ajustan mejor a lo que necesitan los usuarios internos del kernel.

En seguridad, menos código duplicado suele ser positivo: hay menos lugares donde cometer errores, menos rutas divergentes que auditar y más posibilidad de centralizar pruebas. En criptografía, esto es especialmente importante porque pequeños fallos de implementación pueden terminar afectando confidencialidad, integridad o disponibilidad.

5. La mejora de rendimiento llegará por etapas

El propio anuncio técnico aclara que muchos beneficios llegarán en ciclos posteriores, cuando el código optimizado por arquitectura se migre a la biblioteca y cuando más usuarios internos de crypto_skcipher y crypto_aead pasen a las nuevas API. Es decir, Linux 7.3 pone los cimientos; Linux 7.4 y versiones posteriores podrían recoger una parte mayor de las ganancias.

La serie previa de parches ya mostraba por qué hacía falta una biblioteca AES mejorada. En enero de 2026, Eric Biggers explicó que la biblioteca AES existente no aprovechaba código optimizado por arquitectura, podía ser entre 2 y 4 veces más lenta que otras implementaciones software como aes-generic, aes-arm o aes-arm64, y obligaba a calcular claves de cifrado y descifrado incluso cuando muchos modos solo necesitan la dirección de cifrado.

6. Mejor seguridad: zeroization y reducción de superficie peligrosa

Además de las nuevas API para modos AES, el pull request incluye cambios para mejorar la limpieza de claves y contextos en AES-CMAC. En concreto, se agregan funciones de zeroization y se limpian estructuras usadas por SMB, Bluetooth y mac80211 cuando terminan de usarse.

La zeroization es importante porque busca reducir el tiempo que claves o material sensible permanecen en memoria después de usarse. No sustituye otras defensas, pero es una práctica de higiene criptográfica relevante en código de bajo nivel.

7. AF_ALG: el otro debate de seguridad criptográfica en Linux

El ciclo de Linux 7.3 también está marcado por otro movimiento importante: restringir más la interfaz AF_ALG, que permite a programas de espacio de usuario interactuar directamente con la crypto API del kernel. Phoronix reportó que AF_ALG fue deprecado en Linux 7.2 y que para Linux 7.3 se añade un nuevo sysctl /proc/sys/crypto/af_alg_restrict para limitar o deshabilitar su uso.

La razón es clara: AF_ALG ha sido considerado una fuente frecuente de vulnerabilidades y una superficie de ataque difícil de mantener. El nuevo control permite tres niveles: acceso sin restricciones, funcionalidad limitada por defecto o deshabilitación completa. Esto muestra una tendencia doble en el kernel: por un lado, mejorar las rutas internas de criptografía; por otro, reducir exposición innecesaria hacia espacio de usuario.

8. Qué componentes pueden beneficiarse

Las nuevas API no están pensadas para usuarios finales directamente. Están orientadas a desarrolladores del kernel y subsistemas que usan cifrado internamente. Aun así, el impacto puede llegar indirectamente a sistemas que dependen de cifrado intensivo.

9. Por qué esto importa para empresas y administradores Linux

Los administradores no tendrán que cambiar comandos por esta mejora. No habrá una nueva opción mágica en cryptsetup ni una configuración visible en systemd solo por las API AES. Pero sí conviene entender el cambio porque afecta una de las capas más sensibles del servidor: la criptografía del kernel.

En entornos empresariales, el cifrado se usa para proteger discos, respaldos, tráfico, secretos, autenticación, VPN, sistemas de archivos, contenedores y máquinas virtuales. Cuando el kernel mejora sus primitivas internas, se reduce deuda técnica en un componente que muchas organizaciones usan sin verlo.

10. Cómo verificar qué cifrado usa tu servidor Linux

Para administradores, estas mejoras son una buena excusa para auditar el uso de cifrado en servidores. Antes de actualizar kernels, conviene saber si el sistema usa LUKS, dm-crypt, IPsec, WireGuard, SMB cifrado, Bluetooth, certificados, módulos criptográficos o aceleración por hardware.

# Ver algoritmos criptográficos disponibles en el kernel
cat /proc/crypto | grep -E "name|driver|module|priority" | head -80

# Revisar discos cifrados

lsblk -f
cryptsetup status nombre_volumen

# Ver si la CPU tiene aceleración AES en x86

grep -m1 -o aes /proc/cpuinfo

# Ver módulos crypto cargados

lsmod | grep -E "aes|crypto|ghash|xts|gcm|ccm"

# Revisar kernel activo

uname -r

11. Lo que no debe malinterpretarse

12. Preguntas clave

Recomendamos

En resumen

Linux 7.3 introduce una base criptográfica más moderna para AES dentro del kernel. Las nuevas API cubren modos esenciales como ECB, CBC, CTR, XTS, GCM y CCM, simplifican el uso interno, conectan con las pruebas de la crypto API tradicional y preparan el terreno para migrar código optimizado por arquitectura.

La mejora más importante no es solo “más velocidad”, sino mejor arquitectura: menos duplicación, API más claras, mejor documentación, zeroization en áreas sensibles y una ruta más sólida para optimizaciones futuras. En paralelo, el kernel continúa reduciendo superficies criptográficas problemáticas como AF_ALG.