Tassonomia di cifrari / MAC / Kex disponibili in SSH?

Question

Tassonomia di cifrari / MAC / Kex disponibili in SSH?

#1 da (3 voti)
#2 da (0 voti)

9

SSH offre una grande varietà di algoritmi per le opzioni di configurazione Ciphers, MAC e KexAlgorithms. A volte ho bisogno di una connessione veloce e leggera (la mia rete interna), ea volte voglio tutte le protezioni che posso ottenere (VPN a casa da DEFCON).

Esiste una tassonomia di ciò che è più lento / più veloce e più / meno sicuro (dati gli attacchi noti alla riduzione della complessità o l'aumento delle probabilità di collisioni, ecc ...) set di algoritmi per ciascuna delle categorie sopra citate?

Ho letto Quali sono le crittografie realistiche e più sicure per le crittografie Symmetric, Asymmetric, Hash, Message Authentication Code? , ma mi piacerebbe vedere più discussioni su diversi consigli per applicazione (da server many a server vs dispositivo mobile con breve durata della batteria e CPU debole), nonché altri effetti collaterali di diverse modalità di funzionamento (CBC vs CTR vs ECB), diciamo uso interattivo, vs trasferimento di file.

Aggiunta: Ho trovato questo riepilogo di velocità di trasferimento effettive di diversi crittografia algos / modalità.

terminology cryptography ssh

posta Marcin 20.03.2012 - 13:47

fonte

2 risposte

Leggi altre domande sui tag terminology cryptography ssh

Per quanto tempo un computer deve essere spento per resistere a un attacco di avvio a freddo? Un sito web può rilevare la mia rete WIFI locale in cui mi trovo?

score 3 · Answer 1

Una risposta alternativa a quanto detto sopra è che se sei preoccupato per la sicurezza, concentrarti sugli algoritmi è in gran parte irrilevante, perché dove otterrai 0wned è attraverso un bug di implementazione nel tuo server SSH, non attraverso nessuno che attacca la crittografia. In particolare, se stai facendo qualcosa come VPN a casa da DEFCON, devi difenderti da metasploit, non da un cracker del DES. Potresti usare l'algoritmo più debole che SSH supporti normalmente, il singolo DES, ed essere perfettamente sicuro, perché quello che ti porterà è un 0day in OpenSSH o, se non stai eseguendo l'ultima versione, semplicemente quello. Quindi stai davvero facendo la domanda sbagliata, praticamente qualsiasi algoritmo ti terrà al sicuro, sono i bug di implementazione in cui ti cattureranno.

score 0 · Answer 2

È improbabile che la scelta del cipher faccia la differenza sulle prestazioni di SSH. Nella maggior parte dei casi, la tua CPU può crittografare / decifrare più velocemente di quanto la tua rete possa mantenere. Nella maggior parte dei casi, la larghezza di banda della rete sembra essere il fattore limitante.

Pertanto, suggerisco di lasciare SSH alle sue impostazioni predefinite. Stanno bene. Le impostazioni predefinite sono ragionevolmente sicure e non è probabile che la modifica dei valori predefiniti fornisca prestazioni sensibilmente migliori.

Se vuoi davvero giocare con i parametri, puoi controllare l'uso della compressione di SSH. Per impostazione predefinita, tutti i dati verranno compressi prima di inviarli tramite il canale crittografato. Puoi regolare il livello di compressione con ssh -o 'CompressionLevel 6' (sostituisci 6 con qualsiasi numero compreso tra 1 e 9, 1 è il più veloce, 9 è il più lento). Tuttavia, personalmente, non ho trovato guadagni significativi dalla modifica del livello di compressione. Inoltre, se stai trasferendo un file già compresso con scp, puoi disattivare la compressione con scp -o 'Compression no' ... . In alcuni casi (dove hai una rete molto veloce e una CPU lenta), questo potrebbe aiutare alcuni, anche se nella mia esperienza non ho trovato che fa una differenza abbastanza grande per cui valga la pena preoccuparsi.

Modifica 3/20: @Marcin afferma che Blowfish ha ottenuto prestazioni migliori nei suoi test. Delle crittografie supportate sul mio client OpenSSH, tutte le seguenti dovrebbero garantire una sicurezza elevata:

            aes128-ctr,aes192-ctr,aes256-ctr
            aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,
            aes256-cbc

Molto probabilmente arcfour128 , arcfour256 e arcfour forniranno anche una strong sicurezza, sebbene non siano una scelta abbastanza conservativa come le altre. Non dovresti usare des , in quanto fornisce una sicurezza più debole ( 3des va bene). Degli algoritmi del codice di autenticazione dei messaggi (MAC) supportati sul mio client OpenSSH, tutti i seguenti elementi dovrebbero fornire una sicurezza elevata:

               hmac-md5,hmac-sha1,[email protected],
               hmac-ripemd160,hmac-sha1-96,hmac-md5-96

Degli HostKeyAlgorithms supportati sul mio client OpenSSH, tutte le opzioni supportate ( ssh-rsa , ssh-dss ) sono valide e dovrebbero fornire una sicurezza strong, a condizione che si scelga una chiave di lunghezza sufficiente. Non ho familiarità con l'opzione KexAlgorithms.

In breve, in pratica tutte le opzioni crittografiche fornite dovrebbero essere abbastanza sicure, eccetto che non si usi des (e se si è prudenti, si potrebbero evitare le cifrature basate su arcfour , anche se probabilmente solo paranoia) .