AES-256 frente a OFB: elija una construcción de cifrado VPN completa

AES-256 y OFB responden a preguntas distintas, y aquí es donde fallan las revisiones de cifrado cuando se tratan como opciones competidoras. Uno nombra un cifrado de bloque con un tamaño de clave; el otro describe cómo un cifrado de bloque se convierte en un flujo para un mensaje más largo. Un manual para elegir protección debe mirar la construcción completa, incluido cómo el receptor detecta un paquete modificado.

Nombre las cuatro partes de la construcción

Cada revisión se reduce a cuatro preguntas: qué primitiva y tamaño de clave, cómo se procesan los mensajes con ella, cómo el receptor rechaza una modificación no autorizada y cómo el protocolo gestiona las entradas, las claves y su vida útil. Una lista de nombres conocidos solo responde a la primera. La segunda y la tercera son donde viven las diferencias reales, y la cuarta es donde las implementaciones divergen en silencio. Hágaselas en ese orden y escriba las respuestas.

OFB aparece entre los modos de confidencialidad en la publicación de NIST sobre modos de cifrado de bloque, y la confidencialidad es todo lo que ofrece. Un protocolo que empareja un modo de cifrado con un MAC separado debe componerlos correctamente, y el nombre de un algoritmo no demuestra esa composición. Por eso el nombre del modo por sí solo no puede resolver una decisión de despliegue.

La cuarta pregunta es la que un operador puede verificar realmente en el sistema en marcha.

Prefiera una construcción autenticada

El cifrado autenticado aporta confidencialidad e integridad juntas, y las construcciones AEAD también protegen los datos asociados de modificaciones sin cifrarlos. Es una propiedad de la protección de paquetes y no tiene relación con que una persona haya iniciado sesión correctamente.

La Guía de ajustes criptográficos de OpenVPN de Netgate apunta a opciones AEAD, entre ellas AES-GCM, para el canal de datos, y ese es el tipo de política admitida que conviene seguir. Use las opciones que admiten la versión instalada y los clientes pares, en lugar de copiar una clasificación histórica de modos en un despliegue nuevo. La compatibilidad heredada, los backends criptográficos y el soporte de offload limitan lo que está realmente disponible.

Una construcción admitida vence a una composición ingeniosa todas las veces.

Lea el resultado negociado, no la oferta

Un cifrado que aparece en una lista aceptada no dice nada sobre la sesión actual. Lea la protección negociada del canal de datos en el cliente o en la puerta de enlace y compárela con la política que quería aplicar. Una configuración que aún enumera una opción heredada para un par antiguo es una decisión de compatibilidad, no una afirmación sobre la sesión que tiene delante.

openvpn --config client.conf --verb 4 2>&1 | grep -Ei 'cipher|data channel|auth'

En una puerta de enlace la salida equivalente es la asociación de seguridad o el detalle criptográfico de la conexión, según la plataforma. En ambos casos la oferta y el resultado son hechos distintos. Una lista que incluye una opción heredada para un par antiguo no significa que todas las sesiones la usen, y la sesión que sí la usa es lo que necesitaba saber.

Registre ambos hechos juntos, con la fecha y la versión del cliente.

Mida solo lo que puede comparar

El rendimiento depende del hardware de los extremos, la implementación, la aceleración, los tamaños de paquete y la configuración elegida. Ni la longitud de la clave ni la palabra OFB le dicen qué despliegue será más rápido. Por eso una prueba de otro sitio es como mucho una pista sobre el hardware que posee otra persona. Sus propios números empiezan por sus propios extremos.

Para una comparación autorizada, mantenga constantes los extremos, la carga de trabajo y la política requerida, y registre la protección negociada junto con las versiones de implementación. Luego juzgue el resultado por si la aplicación terminó, cuánto perdió y qué estaban haciendo los extremos, en lugar de inferir el coste criptográfico de una sola prueba de velocidad. Un número producido en otras condiciones es un relato, no una medición.

Si un par antiguo no puede cumplir la política, es una decisión de compatibilidad de su propietario.

Mantenga la integridad fuera del trato

Desactivar las comprobaciones de integridad o aceptar un servidor no verificado no es una optimización de rendimiento ni una solución de compatibilidad. Cambia la propiedad de seguridad para la que se eligió la construcción. Lo mismo vale para ampliar la lista de cifrados aceptados hasta que un par antiguo se conecte: la conexión tiene éxito y la política ya no existe.

Escriba la construcción aceptada y su propietario en el manual, para que el próximo cambio empiece por una decisión y no por una preferencia.

Lo que quiere es una política que ambos extremos puedan aplicar. Discutir que un nombre es el más fuerte es otra conversación, y suele terminar sin decisión.