Milyen típusú titkosítást használ az SSH?


Legjobb válasz

Hibrid titkosítást használ. Az aszimmetrikus titkosítást egy munkamenetkulcs létrehozására használják, amelyet viszont egy szimmetrikus rejtjel kulcsaként használnak.

Ezek a szimmetrikus rejtjelek vagy blokkos titkosítások (leggyakrabban AES), vagy ritkábbak (de a tiéd valóban ezt preferálja) olyan adatfolyam-titkosítók, mint a Salsa20, más néven ChaCha.

A blokkos titkosítások használata kicsit bővebb magyarázatot érdemel, mivel jelentős következményei vannak a kommunikáció titkosságával kapcsolatban.

Blokk-rejtjelek NAGYON jók a rögzített méretű blokkok titkosításához – innen származik a nevük. Az SSH hasznos terhelési titkosításaként az a probléma, hogy a parancsok általában nem egy előre meghatározott méretű blokkban érkeznek, az AES 128bit esetén. Tegyük fel, hogy megadta a parancsot

$ ls

Nem egészen 128 bites. Tehát a blokkos titkosítás használatához beindul egy úgynevezett kitöltés – a fennmaradó 104 bitet nullázni (egyszerűsíteni) kell.

Ez azonban problémát vet fel: Feltételezve, hogy egyetlen elküldött csomag tartalmaz legalább egy bizonyos fokig kitöltve, részben ismert sima szövegünk lenne. Ebből idővel (és sok elfogott csomaggal) ki lehet számítani a munkamenet kulcsát.

Annak megakadályozása érdekében, hogy bizonyos rejtjelezési módokat találjanak ki. Hosszú ideig titkosítóblokk-láncolást használtak:

Ez a diagram alapvetően ezt mondja Önnek:

  1. Az első titkosítandó blokkhoz egy előre egyeztetett véletlenszerű adatblokkot használnak úgynevezett inicializációs vektorként.
  2. A sima szöveget és az IV-et Exkluzív Vagy (XOR) művelet: egy művelet meglehetősen könnyű visszaállítani, ha rendelkezik IV-vel, de nagyon-nagyon nehéz, ha nincs.
  3. Most , a kulcs az XOR művelet eredményének titkosítására szolgál.
  4. A kapott titkosítási szöveget ezután a következő blokk IV-ként használják.

Mivel a sima szöveg a titkosítás megadása előtt most nagymértékben módosul, már nincs ismert sima szöveg. Nos, elméletben. Nos, még az sem. A CBC-t már nem tekintik a legkorszerűbbnek, főleg azért, mert egy sikeres támadást Serge Vaudenay publikált. Manapság a Számláló vagy a Galois számláló módokat használják . Kifejezésük kissé kívül esik a kérdés körén, de elegendő azt mondani, hogy a CBC ugyanazon célját teljesítik, de biztonságosnak tekintik őket.

Tehát helyes lenne azt mondani, hogy egy hibrid titkosítást alkalmaznak, aszimmetrikus rejtjelekkel, amelyeket a szerver és adott esetben az ügyfél hitelesítéséhez, valamint a kulcscseréhez használnak, és a kicserélt kulcsot szimmetrikus adatfolyam-titkosításhoz vagy blokkos titkosításhoz használják CBC vagy (G) CTR módban. / p>

Válasz

A2A Mi az SSH fő alternatívája?

Őszintén szólva nem Nem hiszem, hogy van egy. Ez olyan, mintha megkérdeznénk, mi a kerék alternatívája. A protokoll annyira hasznos, biztonságos és nyílt forráskódú, hogy nincs értelme mást fejleszteni. A Telnet SSH-hez csatlakozik, mivel a Travois a kerékhez.

Egyetértek Neil Richins elméleti válaszainak nagy részével, de az NFS nem az SSH / SCP biztonságos alternatívája (LAN-protokoll, nem nyilvános-internetes protokoll), és Mosh SSH-t használ a szállításhoz.

Ha problémákat talál az SSH-ban, azok kijavításra kerülnek. Senki sem hagyja abba az egészet. Ezért használjuk az SSH 2-et az SSH 1 helyett, és sok eredeti titkosító elavult. Olyan, mint az SSL / TLS.

Azt hittem, hogy az FTP a Telnet-nel halt meg, a HTTP (opcionálisan SSL-t használva), az SCP, az SFTP és az Rsync (az SSH-szállítást használva) ölte meg. De akkor azt tapasztaltam, hogy nem volt hajlandó meghalni, és hogy az emberek létrehozott egy biztonságos verziót FTPS. Tehát van ilyen a fájlátvitelhez. Személy szerint az SCP-t és az Rsync-et használom. A fájlátvitel másik alternatívája a HTTP SSL / TLS-sel. A letöltéshez a HTTP GET egyszerűen képes bármilyen fájlt levinni egy webszerverről. Feltöltéshez A HTTP POST akkor működik, ha kezelőt ír és H A TTP PUT akkor működik, ha ezt pl. WebDAV. Tehát a megosztott hely biztonságos protokollon történő fenntartása érdekében a WebDAV az Rsync / SSH alternatívája. A probléma az, hogy az SCP / Rsync fenntartja a fájl tulajdonjogát, míg a WebDAV vagy a POST alkalmazásban bármi feltöltött dolog a webszerver folyamatához tartozik. A CMS rendszerek eleve bizonytalanok abban az értelemben, hogy ha a webszervert feltörik, akkor a webszerver folyamata írási hozzáféréssel rendelkezik az összes tartalomhoz – nincs felhasználói elkülönítés.

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük