¿Existe algún riesgo / beneficio de seguridad al agregar un relleno adicional (más allá de lo que se requiere) cuando se usa AES-256 para cifrar cadenas muy cortas?

El relleno más largo no tiene desventajas en cuanto a seguridad y la ventaja es que filtra menos información sobre la longitud del texto sin formato. El único inconveniente de un mayor relleno es el mayor tamaño del texto cifrado, por lo que siempre que considere que el relleno aceptable para un tamaño mayor de bloque es una buena opción. Por ejemplo, en una aplicación de chat, rellenaría múltiplos de 256 bytes o incluso bloques más grandes.

En principio, cualquier relleno funciona bien, siempre que pueda eliminarlo sin ambigüedades. Recomiendo el relleno determinista en lugar del relleno aleatorio, simplifica las pruebas y evita las preocupaciones sobre los canales ocultos . Una IV adecuada ya agrega toda la aleatoriedad que necesita, y se asume que AES es seguro contra ataques conocidos de texto simple.

Los rellenos típicos son 0x80 seguido de tantos 0x00 como quieras, o tantos 0x00 como quieras, seguido por la longitud del relleno o la longitud del texto en claro. Un solo byte no funciona, ya que no puede saber si un byte todavía es parte del relleno o ya forma parte del mensaje.

Como siempre, recuerde usar un modo de cifrado autenticado con un mensaje por mensaje IV. AES-GCM es popular, pero la opción convencional de AES-CBC combinada con HMAC en el orden de cifrar y luego MAC también está bien, si logras implementarlo correctamente.

Hay una ganancia de seguridad, y es justo lo que mencionaste.

Si un atacante sabe que las diferentes longitudes de cyphertext significan algo, no necesita descifrar el mensaje.

La situación más extrema (libro de texto) es cuando tiene N mensajes, y cada uno tiene una longitud diferente. Si el atacante sabe lo que significa cada uno de esos mensajes, puede deducir el tipo de mensaje, pero aún así perder algunos detalles. Esto sigue siendo un error de seguridad, ya que el atacante puede inferir algo del mensaje, mientras que la criptografía (buena) no debe revelar nada que el atacante no supiera antes de ver el texto cifrado.

En el lado del riesgo, siempre y cuando no uses el modo ECB, deberías estar bien.

El relleno adicional no necesariamente aumenta la seguridad en este escenario. Solo aumenta el tiempo de descifrado. No está realizando ninguna otra operación en la entrada rellenada antes de enviarla a través del algoritmo para el cifrado. Si emplea un protocolo personalizado que realiza operaciones adicionales en el texto plano y utiliza el algoritmo aes, podría haber un aumento en la seguridad. (Por favor, no intentes eso, ya que los protocolos personalizados casi siempre son fáciles de romper hasta que no estén respaldados por Cryptanalysts)

También debes considerar el relleno de los ataques de Oracle. Siempre y cuando no uses ningún esquema de relleno estandarizado y uses bytes aleatorios para el relleno, podrías superar este ataque.