Beste antwoord
Het gebruikt een hybride codering. Asymmetrische cryptografie wordt gebruikt om een sessiesleutel vast te stellen die op zijn beurt wordt gebruikt als sleutel voor een symmetrische code.
Die symmetrische cijfers zijn ofwel blokcijfers (meestal AES) of zeldzamer (maar de jouwe heeft echt de voorkeur) stroomcijfers zoals Salsa20, ook bekend als ChaCha.
Het gebruik van blokcijfers verdient wat meer uitleg, aangezien het aanzienlijke implicaties heeft voor de vertrouwelijkheid van de communicatie.
Blokcijfers zijn ZEER goed voor het versleutelen van blokken met vaste afmetingen – vandaar hun naam. Het probleem bij gebruik als het payload-cijfer voor SSH is dat commandos meestal niet in een blok van een vooraf bepaalde grootte komen, in het geval van de AES 128bit. Laten we nu aannemen dat u het commando
$ ls
invoert. Niet helemaal 128bit. Dus om een blokcijfer te kunnen gebruiken, zou iets dat padding wordt genoemd in werking treden – de resterende 104 bits zouden op nul worden gezet (vereenvoudigd).
Dit vormt echter een probleem: ervan uitgaande dat een enkel verzonden pakket padding, tenminste tot op zekere hoogte, zouden we een gedeeltelijk bekende leesbare tekst hebben. Hieruit zou het na verloop van tijd (en veel vastgelegde pakketten) mogelijk zijn om de sessiesleutel te berekenen.
Om te voorkomen dat bepaalde coderingsmodi werden uitgevonden. Lange tijd werd coderingsblokketting gebruikt:
Wat dit diagram u in feite vertelt, is dit:
- Om het eerste blok te versleutelen, wordt een vooraf onderhandeld blok met willekeurige gegevens gebruikt als een zogenaamde initialisatievector.
- De platte tekst en de IV worden onderworpen aan een Exclusieve of (XOR) operatie: een operatie die vrij gemakkelijk ongedaan kan worden gemaakt als je de IV hebt, maar heel, heel moeilijk als je dat niet hebt.
- Nu , wordt de sleutel gebruikt om het resultaat van de XOR-bewerking te versleutelen.
- De resulterende versleutelde tekst wordt dan gebruikt als de IV voor het volgende blok.
Aangezien de platte tekst zal nu sterk worden gewijzigd voordat de codering wordt ingevoerd, er is geen leesbare tekst meer bekend. Nou ja, in theorie. Nou ja, zelfs dat niet. CBC wordt niet langer als state-of-the-art beschouwd, voornamelijk omdat een succesvolle aanval werd gepubliceerd door Serge Vaudenay . Tegenwoordig worden de Counter-modus of de Galois Counter-modus gebruikt . Het uitleggen ervan valt een beetje buiten het bestek van deze vraag, maar het volstaat te zeggen dat ze hetzelfde doel van CBC vervullen, maar als veilig worden beschouwd.
Het zou dus correct zijn om te zeggen dat een hybride encryptie wordt gebruikt, waarbij asymmetrische codes worden gebruikt voor authenticatie van de server en optioneel de client, evenals de sleuteluitwisseling, waarbij de uitgewisselde sleutel wordt gebruikt voor een symmetrische stroomcijfer of een blokcijfer in CBC- of (G) CTR-modus. / p>
Antwoord
A2A Wat is het belangrijkste alternatief voor SSH?
Eerlijk gezegd, ik don denk niet dat er een is. Dat is als vragen wat het belangrijkste alternatief is voor het stuur. Het protocol is zo nuttig, veilig en open-source dat het geen zin heeft om iets anders te ontwikkelen. Telnet is voor SSH zoals de Travois aan het stuur zit.
Ik ben het in theorie eens met veel van Neil Richins antwoord, maar NFS is niet een veilig alternatief voor SSH / SCP (het is een LAN-protocol, geen openbaar internetprotocol) en Mosh gebruikt SSH voor transport.
Als er problemen zijn gevonden in SSH, worden deze opgelost. Niemand verlaat het hele ding. Daarom gebruiken we SSH 2 in plaats van SSH 1, en veel van de originele cijfers zijn verouderd. Een beetje zoals SSL / TLS.
Ik dacht dat FTP stierf met Telnet, gedood door HTTP (optioneel met SSL), SCP, SFTP en Rsync (met behulp van SSH-transport). Maar toen ontdekte ik dat het had geweigerd te sterven, en dat mensen hadden creëerde een beveiligde versie FTPS. Dus dat is er voor bestandsoverdracht. Persoonlijk gebruik ik SCP en Rsync. Een ander alternatief voor bestandsoverdracht is HTTP met SSL / TLS. Voor downloaden werkt HTTP GET gemakkelijk om elk bestand van een webserver te halen. Voor uploaden, HTTP POST werkt als u een handler schrijft, en H TTP PUT werkt als dat is geïmplementeerd in bijv. WebDAV. Dus voor het onderhouden van een gedeelde ruimte via een beveiligd protocol, is WebDAV een alternatief voor Rsync / SSH. Het probleem daar is dat SCP / Rsync het bestandseigendom behoudt, terwijl in WebDAV of POST alles dat wordt geüpload tot het webserverproces behoort. CMS-systemen zijn inherent onveilig in die zin dat als de webserver wordt gehackt, het webserverproces schrijftoegang heeft tot alle inhoud – er is geen gebruikersscheiding.