Perché SSH utilizza il riempimento casuale?

3

Da 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.

Perché SSH richiede (o raccomanda con SHOULD) il riempimento casuale , a differenza del riempimento non casuale?

E perché RFC 4344 dice che non è necessario quando usi la modalità 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.
    
posta jtpereyda 06.05.2017 - 02:14
fonte

3 risposte

2

Il riempimento è usato per riempire il testo in chiaro fino alla lunghezza del blocco del codice. Questo non è necessario per la modalità contatore, poiché non ha blocchi e può crittografare qualsiasi lunghezza.

Esistono diversi stili di riempimento, alcuni sono ottimizzati per riconoscere le modifiche o la lunghezza effettiva dei dati. Nel caso di sheme SSH in cui un campo extra ha specificato la lunghezza non è necessario alcun modello speciale, quindi il contenuto casuale fornisce le informazioni minime per gli aggressori.

In SSH puoi aggiungere padding più a lungo che alla fine del blocco (ad es. al blocco successivo o anche a più). Ciò aiuta a rendere più difficile per gli attaccanti indovinare la lunghezza effettiva del testo in chiaro.

Soprattutto per le sessioni di comando / risposta si può imparare molto se il codice perde la lunghezza. Questo si chiama analisi del traffico e la lunghezza del padding casuale aiuta un po 'a contrastarlo.

    
risposta data 06.05.2017 - 02:52
fonte
1

I codici a blocchi moderni sono esplicitamente progettati per tenere conto di qualsiasi errore sistematico di input, che potrebbe non introdurre il padding casuale.

The usage of a simple deterministic input function used to be controversial; critics argued that "deliberately exposing a cryptosystem to a known systematic input represents an unnecessary risk." However, today CTR mode is widely accepted and any problems are considered a weakness of the underlying block cipher, which is expected to be secure regardless of systemic bias in its input.

link

    
risposta data 09.05.2017 - 01:32
fonte
0

Un padding casuale di un'area può essere utile per difendersi da certi tipi di attacchi di analisi del tempo. Vedi questo documento, Analisi del tempo nelle reti miste a bassa latenza: attacchi e difese , dall'università di Austin.

Detto questo, il semplice riempimento casuale è una difesa inadeguata rispetto ad alcuni tipi di attacchi di analisi del tempo. Potrei comunque probabilmente dire che stai fumando uno show Netflix anche con il padding casuale. Questa è un'area di interesse per ssh che non ho ancora visto per una soluzione solida.

Come si può difendere ssh dall'analisi dei tempi attacchi?

    
risposta data 08.05.2017 - 21:48
fonte

Leggi altre domande sui tag