Cel mai bun răspuns
Folosește o criptare hibridă. Criptografia asimetrică este utilizată pentru a stabili o cheie de sesiune care la rândul ei este utilizată ca cheie pentru un cifru simetric.
Aceste cifre simetrice sunt fie cifre bloc (cel mai frecvent AES), fie mai rare (dar preferate de dvs. cu adevărat) cifrări de flux, cum ar fi Salsa20, cunoscută și sub numele de ChaCha.
Utilizarea cifrelor bloc merită puțină explicație, deoarece are implicații semnificative în ceea ce privește confidențialitatea comunicării.
Cifrele bloc sunt FOARTE bune pentru criptarea blocurilor de dimensiuni fixe – de unde și numele lor. Problema atunci când este utilizată ca cifru de încărcare utilă pentru SSH este că comenzile nu apar de obicei într-un bloc cu o dimensiune prestabilită, în cazul AES 128 biți. Acum, să presupunem că introduceți comanda
$ ls
Nu chiar pe 128 de biți. Deci, pentru a putea folosi un cifru bloc, ar fi introdus ceva numit padding – restul de 104 biți ar fi zero (simplificat).
Totuși, aceasta impune o problemă: Presupunând că un singur pachet trimis conține umplând cel puțin într-un anumit grad, am avea un text clar parțial cunoscut. Din aceasta, ar fi posibil în timp (și o mulțime de pachete capturate) să se calculeze cheia de sesiune.
Pentru a împiedica inventarea anumitor moduri de cifrare. Pentru o lungă perioadă de timp, s-a folosit înlănțuirea blocurilor de cifrare:
Ce vă spune în principiu această diagramă este:
- Pentru ca primul bloc să fie criptat, un bloc pre-negociat de date aleatorii este folosit ca așa-numitul Vector de inițializare.
- Textul clar și IV sunt supuse unui Operațiune exclusivă sau (XOR) : o operație destul de ușor de revenit dacă aveți IV, dar foarte, foarte greu dacă nu aveți.
- Acum , cheia este utilizată pentru a cripta rezultatul operației XOR.
- Textul cifrat rezultat este apoi folosit ca IV pentru următorul bloc.
Deoarece textul în clar va fi acum puternic modificat înainte de a introduce criptarea, nu mai există niciun text clar cunoscut. Ei bine, în teorie. Ei bine, nici măcar asta. CBC nu mai este considerat stadiul tehnicii, în principal deoarece un atac reușit a fost publicat de Serge Vaudenay . În zilele noastre, se utilizează modul Contor sau modurile Contor Galois . Explicarea lor este puțin în afara domeniului acestei întrebări, dar este suficient să spunem că îndeplinesc același scop al CBC, dar sunt considerate sigure.
Deci, ar fi corect să spunem că un se utilizează criptarea, cu cifre asimetrice utilizate pentru autentificarea serverului și opțional a clientului, precum și schimbul de chei, cheia schimbată fiind utilizată pentru un cifru de flux simetric sau un cod de bloc fie în modul CBC, fie în modul CTR (G).
Răspuns
A2A Care este principala alternativă la SSH?
Sincer, eu nu Nu cred că există una. Este ca și cum ai întreba care este principala alternativă la roată. Protocolul este atât de util, sigur și open-source încât nu are rost să dezvoltăm altceva. Telnet este către SSH, deoarece Travois este la volan.
Sunt de acord cu o mare parte din răspunsul lui Neil Richins în teorie, dar NFS nu este o alternativă sigură la SSH / SCP (este un protocol LAN, nu un protocol public-internet) și Mosh folosește SSH pentru transport.
Dacă se găsesc probleme în SSH, acestea se rezolvă. Nimeni nu abandonează întregul lucru. De aceea folosim SSH 2 în loc de SSH 1 și multe dintre cifrele originale au fost depreciate. Cam ca SSL / TLS.
Am crezut că FTP a murit cu Telnet, ucis de HTTP (opțional folosind SSL), SCP, SFTP și Rsync (folosind transport SSH). Dar apoi am constatat că refuzase să moară și că oamenii au a creat o versiune securizată FTPS. Deci, există pentru transferuri de fișiere. Personal folosesc SCP și Rsync. O altă alternativă pentru transferul de fișiere este HTTP cu SSL / TLS. Pentru descărcare, HTTP GET funcționează ușor pentru a obține orice fișier de pe un server web. Pentru încărcare, HTTP POST funcționează dacă scrieți un handler și H TTP PUT funcționează dacă este implementat în ex. WebDAV. Deci, pentru menținerea unui spațiu partajat peste un protocol sigur, WebDAV este o alternativă la Rsync / SSH. Problema este că SCP / Rsync păstrează calitatea de fișier, în timp ce în WebDAV sau POST orice încărcat aparține procesului serverului web. Sistemele CMS sunt inerente nesigure, deoarece dacă serverul web este piratat, procesul serverului web are acces la scriere la tot conținutul – nu există separare de utilizator.