Hvilken type kryptografi bruker SSH?


Beste svaret

Den bruker en hybrid kryptering. Asymetrisk kryptografi brukes til å etablere en øktnøkkel som igjen blir brukt som en nøkkel for en symmetrisk kryptering.

Disse symmetriske kodingene er enten blokkodere (oftest AES) eller sjeldnere (men foretrukket av deg virkelig) strømkoder som Salsa20, også kjent som ChaCha.

Bruken av blokkryptering fortjener litt mer forklaring, siden den har betydelige implikasjoner med tanke på konfidensialiteten til kommunikasjonen.

Blokker koding er veldig bra for kryptering av blokker med faste størrelser – derav navnet. Problemet når det brukes som nyttelastkryptering for SSH er at kommandoer vanligvis ikke kommer i en blokk med en forutbestemt størrelse, i tilfelle AES 128bit. La oss anta at du skriver inn kommandoen

$ ls

Ikke helt 128bit. Så for å kunne bruke en blokkryptering, vil noe som kalles polstring sparke inn – de resterende 104 bitene vil bli nullstilt (forenklet).

Dette påfører imidlertid et problem: Forutsatt at en enkelt pakke sendt inneholder polstring i det minste til en grad, ville vi ha en delvis kjent ren tekst. Fra dette ville det være mulig over tid (og mange fangede pakker) å beregne øktnøkkelen.

For å forhindre at visse krypteringsmodi ble oppfunnet. I lang tid ble krypteringsblokkjetting brukt:

Hva dette diagrammet i utgangspunktet forteller deg er dette:

  1. For at den første blokken skal krypteres, brukes en forhåndsforhandlet blokk med tilfeldige data som en såkalt initialiseringsvektor.
  2. Retttekst og IV blir utsatt for en Eksklusiv Or (XOR) -operasjon: en operasjon som er ganske enkel å tilbakestille hvis du har IV, men veldig, veldig vanskelig hvis du ikke har det.
  3. Nå blir nøkkelen brukt til å kryptere resultatet av XOR-operasjonen.
  4. Den resulterende krypteringsteksten blir deretter brukt som IV for neste blokk.

Siden ren tekst vil nå bli kraftig modifisert før du går inn i krypteringen, det er ingen kjent klartekst lenger. I teorien. Vel, ikke engang det. CBC regnes ikke lenger som moderne, hovedsakelig fordi et vellykket angrep ble publisert av Serge Vaudenay . I dag brukes Tellermodus eller Galois Counter-modus . Å forklare dem er litt utenfor omfanget av dette spørsmålet, men det er nok å si at de oppfyller det samme formålet med CBC, men blir ansett som sikre.

Så det ville være riktig å si at en hybrid kryptering brukes, med asymmetriske krypter som brukes til autentisering av serveren og eventuelt klienten så vel som nøkkelutvekslingen, hvor den utvekslede nøkkelen brukes til en symmetrisk strømkryptering eller en blokkryptering i enten CBC- eller (G) CTR-modus.

Svar

A2A Hva er hovedalternativet til SSH?

Helt ærlig, det gjør jeg ikke tror ikke det er en. Det er som å spørre hva som er hovedalternativet til hjulet. Protokollen er så nyttig, sikker og åpen kildekode at det ikke nytter å utvikle noe annet. Telnet er for SSH som Travois er for rattet.

Jeg er enig i mye av Neil Richins svar i teorien, men NFS er ikke et sikkert alternativ til SSH / SCP (det er en LAN-protokoll, ikke en offentlig internettprotokoll) og Mosh bruker SSH for transport.

Hvis det er problemer funnet i SSH, blir de løst. Ingen forlater det hele. Derfor bruker vi SSH 2 i stedet for SSH 1, og mange av de opprinnelige kodene er utfaset. Litt som SSL / TLS.

Jeg trodde FTP døde med Telnet, drept av HTTP (valgfritt ved bruk av SSL), SCP, SFTP og Rsync (ved bruk av SSH-transport). Men så fant jeg ut at den hadde nektet å dø, og at folk hadde opprettet en sikker versjon FTPS. Så det er det for filoverføring. Personlig bruker jeg SCP og Rsync. Et annet alternativ for filoverføring er HTTP med SSL / TLS. For nedlasting fungerer HTTP GET enkelt for å få alle filer fra en webserver. For opplasting, HTTP POST fungerer hvis du skriver en handler, og H TTP PUT fungerer hvis det er implementert i f.eks. WebDAV. Så for å opprettholde et delt rom over en sikker protokoll, er WebDAV et alternativ til Rsync / SSH. Problemet der er at SCP / Rsync opprettholder fil eierskap, mens alt som er lastet opp i WebDAV eller POST tilhører webserverprosessen. CMS-systemer er iboende usikre ved at hvis webserveren blir hacket, har webserverprosessen skrivetilgang til alt innholdet – det er ingen brukerseparasjon.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *