CFB1, CFB8 y CFB128: es el tamaño de la realimentación, no el de la clave

Un nombre como AES-256-CFB1 lleva dos números, y responden a preguntas distintas. El 256 es la longitud de la clave AES. El 1 es la realimentación, o el tamaño del segmento, de CFB: una propiedad de cómo el modo avanza su estado. Si el 1 se lee como una longitud de clave, el nombre parece una configuración catastrófica, y por eso la pregunta vuelve una y otra vez.

Decida cuál de las tres cantidades está mirando antes de juzgar el nombre: tamaño de clave, tamaño de bloque o tamaño de segmento. Solo la primera es un parámetro de seguridad en el sentido habitual.

Tres números, tres cantidades

AES acepta claves de 128, 192 o 256 bits y tiene un bloque de 128 bits elija lo que elija. El tamaño del bloque pertenece a AES, no al modo. El sufijo CFB es la tercera cantidad: cuántos datos consume y devuelve el modo en cada paso. La documentación de OpenSSL sobre AES enumera explícitamente esos tamaños de desplazamiento para las variantes CFB.

CFB1 devuelve un bit cada vez, CFB8 un byte, CFB128 un bloque completo. Los tres usan internamente el mismo cifrado de bloque de 128 bits; lo que cambia es cuántos bits de cada bloque calculado se usan por operación. Por eso el sufijo mueve el coste y el comportamiento de búfer, no la fuerza de la clave.

Por qué el tamaño del bloque nunca cambia

AES es un cifrado de bloque con un bloque fijo de 128 bits, y los modos son construcciones a su alrededor. Ninguno de ellos reduce el bloque para ajustarlo al tamaño del segmento. Una implementación de CFB1 sigue calculando un bloque AES completo y toma un bit del resultado. Los demás bits se descartan en ese paso, y ahí está exactamente el coste de eficiencia.

Así que una realimentación de un bit no implica una clave de un bit, y un nombre no puede ordenarse por su sufijo. CFB128 no es cuatro veces más fuerte que CFB32; procesa segmentos más grandes.

Qué cambia realmente el tamaño del segmento

El tamaño del segmento cambia cuánto texto cifrado se devuelve en cada paso y cuánto texto plano puede transportar cada paso. También cambia la propagación de errores y el comportamiento de búfer, lo que importa para un uso similar a un flujo. Los segmentos orientados a bytes se alinean con los búferes; los orientados a bits, no.

En la práctica, el modo lo elige el protocolo, no el operador. Un canal de datos de VPN usa la construcción que especifica su protocolo, con su propia protección de integridad, y un listado de biblioteca solo dice qué nombres existen.

Leer una etiqueta CFB sin calificar

Una etiqueta CFB sin calificar necesita el contexto de su implementación. En las cabeceras de OpenSSL 1.0.2, EVP_aes_128_cfb es una macro para EVP_aes_128_cfb128, con alias equivalentes para claves de 192 y 256 bits. Es una convención de nombres de API de una rama, no la afirmación de que cada biblioteca, formato de archivo o GUI expanda la abreviatura del mismo modo. Compruebe la cabecera o la documentación de la versión que tiene delante.

Si un perfil antiguo dice CFB y el par lo acepta, los parámetros negociados se registran en algún sitio: un registro, un volcado de configuración, una respuesta de API. Léalos en lugar de deducir el tamaño del segmento a partir de una cadena de pantalla.

Lo que un nombre de modo no le dice

El nombre describe el comportamiento del cifrado y nada más. Una VPN sigue necesitando protección de integridad, derivación de claves y autenticación del par, y CFB no aporta ninguna. Cambiar CFB8 por CFB1 tampoco es un cambio cosmético: el comportamiento en la red difiere y ambos extremos deben admitir la misma construcción. Ni un nombre en una biblioteca demuestra que la puerta de enlace desplegada lo acepte para su canal de datos.

Para cualquier cosa mantenida, use el conjunto completo de protección del protocolo y la política del operador, y registre las versiones de biblioteca y puerta de enlace, la opción exacta y el resultado negociado. El nombre antiguo explica qué está leyendo; no justifica revivir la configuración.