Paras vastaus
Se käyttää hybridisalausta. Asymmetristä salausta käytetään istuntoavaimen luomiseen, jota puolestaan käytetään symmetrisen salauksen avaimena.
Nämä symmetriset salaukset ovat joko lohkosalauksia (yleisimmin AES) tai harvinaisempia (mutta sinun todella suosimia) stream-salaukset, kuten Salsa20, joka tunnetaan myös nimellä ChaCha.
Lohkosalaajien käyttö ansaitsee hieman enemmän selityksiä, koska sillä on merkittäviä vaikutuksia viestinnän luottamuksellisuuteen.
Lohkosalaimet ovat ERITTÄIN hyviä kiinteän kokoisten lohkojen salaamiseen – tästä johtuen niiden nimi. SSH: n hyötykuorman salauksena käytettäessä ongelma on se, että komennot eivät yleensä tule ennalta määrätyn kokoisissa lohkoissa, AES 128bit: n tapauksessa. Oletetaan nyt, että kirjoitat komennon
$ ls
Ei aivan 128-bittinen. Joten voidakseen käyttää lohkosalausta, jotain, jota kutsutaan pehmustukseksi, laukaisisi – loput 104 bittiä nollattaisiin (yksinkertaistettaisiin).
Tämä aiheuttaa kuitenkin ongelman: Olettaen, että yksi lähetetty paketti sisältää täytteen ainakin jossain määrin, meillä olisi osittain tiedossa selkeä teksti. Tämän perusteella olisi mahdollista ajan mittaan (ja paljon siepattuja paketteja) laskea istuntoavain.
Estetään tiettyjen salausmoodien keksiminen. Pitkään käytettiin salauslohkoketjua:
Tämä kaavio kertoo sinulle periaatteessa tämän:
- Ensimmäiseksi salatuksi lohkoksi käytetään ennalta neuvoteltua satunnaisdatalohkoa ns. Initialization Vektorina.
- Selkokieliselle tekstille ja IV: lle tehdään Yksinomainen tai (XOR) -operaatio: operaatio, joka on melko helppo palauttaa, jos sinulla on IV, mutta erittäin, erittäin vaikea, jos sinulla ei ole.
- Nyt , avainta käytetään XOR-operaation tuloksen salaamiseen.
- Tuloksena olevaa salaustekstiä käytetään sitten seuraavan lohkon IV: nä.
Koska selkeä teksti modifioidaan nyt voimakkaasti ennen salauksen syöttämistä, ei ole enää tunnettua selkeää tekstiä. No, teoriassa. No, ei edes sitä. CBC: tä ei enää pidetä huipputasona lähinnä siksi, että Serge Vaudenay julkaisi onnistuneen hyökkäyksen. Nykyään käytetään laskuritilaa tai Galois-laskurin tilaa . Niiden selittäminen on hieman tämän kysymyksen ulkopuolella, mutta riittää sanomaan, että ne täyttävät saman CBC-tarkoituksen, mutta katsotaan turvallisiksi.
Joten olisi oikein sanoa, että hybridi salausta käytetään, epäsymmetrisillä salakirjoilla, joita käytetään palvelimen ja valinnaisesti asiakkaan todentamiseen sekä avaintenvaihtoon, vaihdettua avainta käytetään symmetriseen stream-salaukseen tai lohkosalaukseen joko CBC- tai (G) CTR-tilassa. / p>
Vastaus
A2A Mikä on tärkein vaihtoehto SSH: lle?
Suoraan sanottuna en Luulen, että on yksi. Se on kuin kysyisit, mikä on pyörän tärkein vaihtoehto. Protokolla on niin hyödyllinen, turvallinen ja avoimen lähdekoodin, että ei ole mitään järkeä kehittää mitään muuta. Telnet on SSH: lle, koska Travois on pyörässä.
Olen samaa mieltä Neil Richinsin teorian suuresta vastauksesta, mutta NFS ei ole turvallinen vaihtoehto SSH / SCP: lle (se on lähiverkkoprotokolla, ei julkinen Internet-protokolla), ja Mosh käyttää SSH: tä kuljetukseen.
Jos SSH: ssä on ongelmia, ne korjautuvat. Kukaan ei hylkää koko asiaa. Siksi käytämme SSH 2: ta SSH 1: n sijasta, ja monet alkuperäisistä salakirjoista ovat vanhentuneet. Tällainen kuin SSL / TLS.
Luulin, että FTP kuoli Telnetin kanssa, tappoi HTTP (valinnaisesti SSL: ää käyttämällä), SCP, SFTP ja Rsync (käyttäen SSH-kuljetusta). Mutta sitten huomasin, että se oli kieltäytynyt kuolemasta ja että ihmisillä oli loi suojatun version FTPS. Joten tiedostojen siirtoon on olemassa. Henkilökohtaisesti käytän SCP: tä ja Rsync: ää. Toinen vaihtoehto tiedostojen siirtämiselle on HTTP SSL / TLS: llä. Lataamista varten HTTP GET toimii helposti kaikkien tiedostojen poistamiseksi verkkopalvelimelta. HTTP POST toimii, jos kirjoitat käsittelijän ja H TTP PUT toimii, jos se on toteutettu esim. WebDAV. Joten WebDAV on jaettu tila ylläpitämällä suojattua protokollaa Rsync / SSH: lle. Ongelma on, että SCP / Rsync ylläpitää tiedostojen omistajuutta, kun taas WebDAV: ssä tai POST: ssa kaikki ladatut kuuluvat verkkopalvelinprosessiin. CMS-järjestelmät ovat luonnostaan epävarmoja siinä mielessä, että jos verkkopalvelinta hakkeroidaan, verkkopalvelinprosessilla on kirjoitusoikeus kaikkeen sisältöön – käyttäjiä ei eroteta toisistaan.