Puoi dire a OpenSSH di forzare un rekey in base al limite del numero di pacchetti?

La tua risposta è parzialmente indirizzata nella pagina man SSH:

 RekeyLimit
     Specifies the maximum amount of data that may be transmitted
     before the session key is renegotiated, optionally followed a
     maximum amount of time that may pass before the session key is
     renegotiated.  The first argument is specified in bytes and may
     have a suffix of 'K', 'M', or 'G' to indicate Kilobytes,
     Megabytes, or Gigabytes, respectively.  The default is between
     '1G' and '4G', depending on the cipher.  The optional second
     value is specified in seconds and may use any of the units docu-
     mented in the TIME FORMATS section.  The default value for
     RekeyLimit is ''default none'', which means that rekeying is per-
     formed after the cipher's default amount of data has been sent or
     received and no time based rekeying is done.

Un valore predefinito è già impostato su 1Gig e 4Gig di dati, ma cosa significa? Se si inviano pacchetti di dimensioni ridotte, il re-keying impiegherà molto tempo, se si inviano pacchetti di grandi dimensioni, il re-keying si verifica più frequentemente. Quindi, lasciatemelo chiedere: "Quale pensi che il tuo obiettivo sia nell'impostare questo sugli importi del pacchetto?"

Il rekeying è stato fatto in modo che nessuno potesse memorizzare / ottenere / annusare blocchi di dati per gli attacchi di crittanalisi. (E o attacchi di canali laterali). C'è un costo per l'esecuzione di questi tipi di attacchi: archiviazione, tempo, conoscenza della crittografia / crittanalisi. Al di fuori dei programmi sponsorizzati dallo stato nazionale per attaccare questo, non ho ancora visto, letto o sentito parlare di un attore non statale che stia tentando di estrapolarlo. Esistono altri modi per attaccare un sistema.

Ma per rispondere alla tua domanda, non esiste un metodo definitivo elencato per fare questo (rekeying a pacchetti) in modo da avere un'opzione: baseline il traffico, dividi i dati totali inviati, dai pacchetti inviati, quindi usali come numero di rekey. Per esempio. 1Gig di traffico / 1000 pacchetti (quantità media di pacchetti necessari per inviare 1Gig) = Numero di Rekey.

Mi rendo conto che questa è una vecchia domanda, ma altri potrebbero inciampare su di essa. @ La domanda di Pandrei è valida per gli utenti di Common Criteria. Tuttavia, come indica @munkeyoto, OpenSSH ti dà maniglie per giocare con il volume di dati. Quello che @Pandrei non sembrava capire era che con 1 GB di dati, si tratta di pacchetti 2 ^ 28 dati la dimensione di pacchetto più piccola possibile nel protocollo SSH per un algoritmo di crittografia specifico (16 byte). Pertanto, se si imposta il limite di dati a 1 GB, si sarà automaticamente conformi al profilo di protezione NDcPP CC. Il numero di pacchetti è irrilevante dal momento che puoi semplicemente fare matematica per calcolare il numero di pacchetti che dipende dall'algoritmo di crittografia che è stato negoziato. In particolare, vedere la sezione 9.3.2 di RFC 4251:

Because MACs use a 32-bit sequence number, they might start to leak information after 2^32 packets have been sent. However, following the rekeying recommendations should prevent this attack. The transport protocol [SSH-TRANS] recommends rekeying after one gigabyte of data, and the smallest possible packet is 16 bytes. Therefore, rekeying SHOULD happen after 2^28 packets at the very most.

Alla fine, questo è discutibile, dal momento che la v2.0 di NDcPP sostituirà la necessità di reimpostare pacchetti basati su dati e limiti temporali come da raccomandazioni RFC.