Relleno: algoritmo de cifrado

Question

Estoy escribiendo una implementación del algoritmo de cifrado XXTEA que funciona en " streams " ;, es decir, se puede usar como: crypt mykey < myfile > salida.

Uno de los requisitos es que no tiene acceso al archivo (solo lee un bloque de tamaño fijo hasta encontrar un EOF). El algoritmo necesita que los bytes de datos sean múltiplos de 4, por lo que es necesario agregar un relleno.

Para texto plano, una buena solución es rellenar con NULL, y en el descifrado simplemente ignorar los NULL, pero la misma estrategia no se puede usar para flujos binarios (que pueden contener NULL incrustados).

He leído las soluciones comunes, como el relleno con el número de caracteres faltantes (si faltan 3 caracteres, luego agregue un 3, 3, 3 al final) y etc., pero me pregunto: hay una solución más elegante ?

Answer 1

Al leer la pregunta, parece que el aspecto de seguridad de esto es discutible. En pocas palabras, tiene una API que espera un múltiplo de 4 bytes como entrada, que no siempre tiene.

Agregar hasta 3 bytes en cualquier secuencia binaria es peligroso si no puede garantizar que la secuencia binaria no le importe. Agregar 0 al final de un archivo exe no importa, ya que los archivos exe tienen encabezados que especifican los tamaños relevantes de todos los bits restantes. Agregar 0 al final de un archivo pcx lo rompería ya que los archivos pcx tienen un encabezado que inicia un número específico de bytes desde el final del archivo.

Entonces, realmente no tienes otra opción: no hay una opción de bytes de relleno mágico que puedas usar que garanticen que nunca ocurrirán naturalmente al final de una secuencia binaria: debes siempre agregar al menos uno dword de información adicional que describe los bytes de relleno utilizados.

Answer 2

Leer: http://msdn.microsoft .com / es-us / library / system.security.cryptography.paddingmode.aspx

Tiene una lista de métodos de relleno comunes, como:

PKCS7: la cadena de relleno PKCS # 7 consta de una secuencia de bytes, cada uno de los cuales es igual al número total de bytes de relleno agregados.

La cadena de relleno ANSIX923 consiste en una secuencia de bytes llenos de ceros antes de la longitud.

La cadena de relleno ISO10126 consta de datos aleatorios antes de la longitud.

Ejemplos:

Datos sin procesar: 01 01 01 01 01

PKCS # 7: 01 01 01 01 01 03 03 03

ANSIX923 01 01 01 01 01 00 00 03

ISO10126: 01 01 01 01 01 CD A9 03

Answer 3

Lea sobre robo de texto cifrado . Podría decirse que es mucho más elegante que el relleno de texto sin formato. Además, sugeriría usar un tamaño de bloque mayor de 4 bytes: 64 bits es probablemente el mínimo.

Hablando estrictamente, la criptografía de bricolaje es una idea peligrosa; Es difícil superar los algoritmos que toda la comunidad de cifrado ha intentado y no ha podido romper. Diviértete y considera leer esto , ¡o al menos algo de Schneier's quot; lectura relacionada " sección.

Answer 4

En realidad, esperaría que un buen cifrado de flujo no necesite ningún relleno. RC4, por ejemplo, no necesita relleno y es un cifrado de flujo muy fuerte. Sin embargo, puede ser atacado si el atacante puede alimentar diferentes datos elegidos a la rutina de cifrado, que siempre usa la misma clave y también tiene acceso a los datos cifrados. La elección de los datos de entrada correctos y el análisis de los datos de salida se pueden utilizar para restaurar la clave de cifrado, sin un ataque de fuerza bruta; pero aparte de eso, RC4 es muy seguro.

Si necesita relleno, no es un cifrado de flujo en mi humilde opinión. Como si fuera un múltiplo de 4 bytes o un múltiplo de 16 bytes, ¿cuál es la gran diferencia? Y si está acolchado para ser un múltiplo de 16 bytes, podría usar prácticamente cualquier cifrado de bloque. En realidad, su cifrado es un cifrado de bloque, solo funciona con bloques de 4 bytes. Era un cifrado de flujo en un sistema donde cada & Quot; símbolo & Quot; es de 4 bytes (por ejemplo, cuando se cifra el texto UTF-32, en cuyo caso los datos siempre serán un múltiplo de 4, por lo que nunca habrá relleno).