¿Por qué SSH usa relleno aleatorio?

3

De RFC 4253 :

   Each packet is in the following format:

      uint32    packet_length
      byte      padding_length
      byte[n1]  payload; n1 = packet_length - padding_length - 1
      byte[n2]  random padding; n2 = padding_length
      byte[m]   mac (Message Authentication Code - MAC); m = mac_length

      [...]

      random padding
         Arbitrary-length padding, such that the total length of
         (packet_length || padding_length || payload || random padding)
         is a multiple of the cipher block size or 8, whichever is
         larger.  There MUST be at least four bytes of padding.  The
         padding SHOULD consist of random bytes.  The maximum amount of
         padding is 255 bytes.

¿Por qué SSH requiere (o recomienda con DEBERÍA) el relleno aleatorio , en lugar del relleno no aleatorio?

¿Y por qué RFC 4344 dice que no es necesario cuando se usa el modo CTR?

   As an additional note, when one of the stateful-decryption counter
   mode encryption methods (Section 4) is used, then the padding
   included in an SSH packet (Section 4 of [RFC4253]) need not be (but
   can still be) random.  This eliminates the need to generate
   cryptographically secure pseudorandom bytes for each packet.
    
pregunta jtpereyda 06.05.2017 - 02:14
fuente

3 respuestas

2

El relleno se utiliza para rellenar texto sin formato en la longitud de bloque del cifrado. Esto no es necesario para el modo de contador, ya que no tiene bloques y puede cifrar cualquier longitud.

Hay diferentes estilos de relleno, algunos están optimizados para reconocer los cambios o la longitud real de los datos. En el caso del esquema SSH donde un campo adicional especifica la longitud, no se necesita un patrón especial, por lo que el contenido aleatorio proporciona la menor información para los atacantes.

En SSH puede agregar un relleno más largo que al final del bloque (es decir, al siguiente bloque o incluso más). Esto ayuda a dificultar a los atacantes adivinar la longitud real del texto plano.

Especialmente para las sesiones de comando / respuesta se puede aprender mucho si el cifrado pierde la longitud. Esto se denomina análisis de tráfico y la longitud de relleno aleatoria ayuda un poco contra él.

    
respondido por el eckes 06.05.2017 - 02:52
fuente
1

Los cifrados de bloque modernos están diseñados explícitamente para tener en cuenta cualquier sesgo de entrada sistémico, que no se puede introducir mediante un relleno aleatorio.

  

El uso de una función de entrada determinista simple solía ser   polémico; los críticos argumentaron que " exponiendo deliberadamente una   Cryptosystem a una entrada sistemática conocida representa una innecesaria   riesgo . "Sin embargo, hoy en día el modo CTR es ampliamente aceptado y cualquier problema   se consideran una debilidad del cifrado de bloque subyacente, que es   Se espera que sea seguro independientemente del sesgo sistémico en su entrada .

enlace

    
respondido por el Zamicol 09.05.2017 - 01:32
fuente
0

Un área de relleno aleatorio puede ser útil para defenderse contra ciertos tipos de ataques de análisis de tiempo. Vea este documento, Análisis de tiempo en redes de mezcla de baja latencia: ataques y defensas , de la Universidad de Austin

Dicho esto, el relleno aleatorio simple es una defensa deficiente contra ciertos tipos de ataques de análisis de tiempo. Probablemente aún podría decirte que estás al vapor de un programa de Netflix incluso con un relleno aleatorio. Esta es un área de preocupación para ssh que aún no he visto una solución sólida.

¿Cómo puede ssh defenderse contra el análisis de temporización? ataques?

    
respondido por el Zamicol 08.05.2017 - 21:48
fuente

Lea otras preguntas en las etiquetas