Berichten worden versleuteld met de private key en ontsleuteld met de public key!

Even doorlezen...
https://en.wikipedia.org/wiki/Public-key_cryptography

TLS is een hybride encryptie systeem. Er vind dus uitwisseling plaats van symmetrische sleutels om de bulk data te versleutelen. De symmetrische sleutel wordt gegenereerd door aan beide kanten een eigen key te maken en deze via een key exchange te combineren tot 1 gezamelijke sleutel. De server zet dan nog een digitale handtekening op die uitwisseling (met zijn private key van het certificaat) en stuurt het certificaat mee. Client kan dan controleren of de handtekening over de uitwisseling klopt bij de server waar hij mee wilde verbinden.

De client hoeft dus GEEN eigen private key te hebben o.i.d. er is alleen sprake van een gezamenlijke symmetrische AES key.

Bij https, dat tegenwoordig gebruik maakt van TLS (SSL is onveilig en opgevolgd door TLS), hoort de private key, passende bij de public key in het webservercertificaat, de webserver nooit te verlaten (hooguit voor een back-up).

Een van de eerste dingen die een webserver doet aan het begin van een https sessie (net daarvoor gestart door de client), is het naar de client sturen van het webservercertificaat (dit gebeurt nog via een onversleutelde verbinding). De client checkt vervolgens of het certificaat geldig is, wordt vertrouwd en is uitgegeven voor de domeinnaam uit de URL die de gebruiker heeft opgegeven; zo niet dan geeft de client een foutmelding.

Bij oudere ciphers genereerde de client een random getal, dat de client vervolgens met de public key uit het webservercertificaat versleutelde en naar de webserver stuurde. Omdat -als het goed is- alleen de server over de bijpassende private key beschikt, is die webserver de enige die de versleutelde waarde kan ontsleutelen. Dat random getal werd vervolgens door zowel client als server gebruikt als nieuwe sleutel voor symmetrysche encryptie, waarmee de rest van de sessie werd versleuteld (en aan de ontvangende kant ontsleuteld).

Bij de vandaag de dag gebruikelijke ciphers met forward secrecy, wordt de symmetrische sessiesleutel middels het Diffie-Hellman algoritme overeengekomen. Het webservercertificaat en bijbehorende private key op de server dienen uitsluitend nog ter authenticatie van de webserver (die moet bewijzen over de private key te beschikken door een door de client gegenereerd getal te kunnen ontsleutelen).

Als dat al zou kunnen, is het niet erg zinvol (het is wel een soort signeren). Immers iedereen kan de public key hebben, dus iedereen zou dan kunnen ontsleutelen!

Asymmetrische encryptie (dus met public en private keys) is, vergeleken met symmetrische encryptie, beretraag. Daarom wordt het in de praktijk gebruikt voor het versleutelen van hooguit tientallen bytes.

Versleutelen
Als je een bestand of een verbinding wilt versleutelen (zodanig dat alleen geautoriseerden kunnen ontsleutelen), wordt eerst een symmetrische sleutel gegenereerd (of zoveel sleutels als er ontvangers zijn). Elke van die sleutel(s) wordt versleuteld met de public key(s) van de beoogde ontvanger(s). Die public key(s) zul je dus eerst in je bezit moeten hebben, en je zult zeker moeten weten dat ze daadwerkelijk toebehoren aan de bedoelde persoon (of personen). Naar elke ontvanger stuur je vervolgens de met zijn/haar public key verleutelde symmetrische sleutel, en het -met die symmetrische sleutel- versleutelde bestand.

Signeren
Als je een bestand digitaal wilt ondertekenen, kun je -in theorie- een kopie van dat bestand versleutelen met jouw private key. Als je vervolgens het versleutelde exemplaar naar een ontvanger stuurt, kan die ontvanger dat ontsleutelen met jouw public key en concluderen dat het bestand ongewijzigd moet zijn sinds het werd versleuteld met eerdergenoemde private key. Helaas ligt hierbij het risico op "tampering" (wijzigen) van de versleutelde data op de loer - op deze manier is er geen sprake van een cryptografische integriteitscheck, en dat was nou net de bedoeling bij digitale handtekeningen.

Daarom maken digitale handtekeningen in de praktijk gebruik van cryptografische hashes. De verzender berekent de hash (bijv. SHA256) over het bestand, en versleutelt die hash met haar/zijn private key. Het resultaat (de versleutelde hash) is de digitale handtekening. Deze kan in een separaat bestandje worden meegestuurd, of (zoals bij digitaal gesigneerde PDF's en uitvoerbare bestanden), achter het bestand worden "geplakt". De ontvanger berekent ook de hash over het bestand, en vergelijkt deze met de ontvangen hash - na die laatste met de public key te hebben ontsleuteld.

Wie heeft/hebben de private key
In alle gevallen geldt dat je precies wilt weten wie een private key in bezit heeft en dat die private key niet is gelekt. Hoewel dat laatste erg lastig vast te stellen valt, is het in elk geval belangrijk dat je zeker weet dat de bijpassende public key van de veronderstelde persoon is.

Kortom, om te versleutelen gebruik je de public key van de ontvanger, en signeren doe je met jouw private key.

Ovrigens wordt het afgeraden om een sleutelpaar zowel voor signeren als voor versleutelen te gebruiken. Als je een PGP/GPG/Gnupg "sleutel" genereert, zijn dat in de praktijk dan ook twee sleutelparen. De private key uit één van die sleutelparen gebruik je uitsluitend om te signeren, de private key uit het andere sleutelpaar gebruik je alleen om te ontsleutelen.

In mijn 1e bijdrage schreef ik:

In de praktijk werkt het authenticeren door de webserver niet zo vereenvoudigd als ik tussen de () schreef, Acrimony verwoordde dit beter (boven mijn 1e bijdrage):

Hoe zo'n digitale handtekening werkt heb ik hierboven uitgelegd.

Nb. buiten die digitale handtekening, spelen -bij moderne forward-secrecy ciphers- de public key in het certificaat en de bijbehorende private key op de server geen enkele rol meer bij de versleuteling van verbindingen met die webserver.

Als je met wireshark een handshake bekijkt worden dit soort dingen vaak duidelijker.

Lees ook https://isc.sans.edu/forums/diary/Psst+Your+Browser+Knows+All+Your+Secrets/16415/ eens om echt in het verkeer te kunnen kijken.

Dit kwam al naar voren in een AIVD challenge enkele jaren geleden, toen moest je https streams ontsleutelen met Wireshark.

Zet je eigen beveiligingssysteem op door zelf ondertekende SSL certificaten in een kleine eigen groep met elkaar uit te wisselen. https://sites.google.com/site/certificaatversleuteling/home

Aangezien elke browser tegenwoordig klaagt over self signed certificates zet ik persoonlijk alles gewoon op met Let's Encrypt. Is best wel simpel te doen, en geen klagende browser en security exceptions die je moet accepteren

Per verbinding wordt aan client zijde een public/private keypair gegenereerd.

U heeft toen u een certificaat van Let's Encrypt ophaalde eerst het wachtwoord moeten invoeren en heb daarna het certificaat van hen ontvangen. Hoe zeker bent u dat Let's Encrypt betrouwbaar met uw certificaat en wachtwoord omgaat. Zelf ondertekende certificaten kunt u zonder enig probleem voor veilig e-mail verkeer gebruiken. zie de link.

Kijk hier eens:

https://www.youtube.com/watch?v=NmM9HA2MQGI

Of zoek op youtube naar "Computerphile diffie hellman". Hij geeft in een ander filmpje ook duidelijk uitleg over "Elliptic Curve".

Encryptie voor leken (en waarom verzwakken onverstandig is) van ene Erik van S. :

https://www.security.nl/posting/468370/Encryptie+voor+leken+-+en+waarom+verzwakken+onverstandig%2C+en+verbieden+zinloos+is

https://www.youtube.com/watch?v=U62S8SchxX4