ClickySkip to main content
Nu hulp nodig bij een cyberincident?
Bel 24/7: 088-2747800

Checksums en hashes

Door 26 februari 2019 oktober 22nd, 2020 Blog
checksums

Checksums en hashes zijn aan elkaar gerelateerd en worden zeer veel gebruikt in de IT en op allerlei plaatsen; van databases, tot bestandssystemen en wachtwoord databases.

Hashing algoritmes, die een speciale vorm zijn van een checksum, worden ook gebruikt voor het maken van een Blockchain. Om te kunnen begrijpen hoe een Blockchain werkt komt de kennis over hashing algoritmes goed van pas.

Maar om te begrijpen wat een hash is beginnen we met een checksum.

Stel je voor, je hebt een trage en onbetrouwbare netwerkverbinding en je wilt iemand een plaatje sturen. Naarmate het plaatje groter wordt, wordt de kans groter dat er iets fout gaat in de transmissie. Een oplossing is om het plaatje twee of meerdere keren te verzenden. Als de ontvanger twee dezelfde plaatjes heeft, dan is de kans groot dat dat het juiste plaatje is.

Dit is echter wel een heel bewerkelijk en langdurig proces. Stel dat er een wiskundige bewerking is die het plaatje kan omzetten in iets veel korters. Dan zou dat na het plaatje verzonden kunnen worden om vast te stellen of het plaatje goed aangekomen is.

Deze wiskundige bewerking, ook wel een checksum algoritme genoemd, moet voor dit doel wel voldoen aan een aantal eisen:

1) HIJ MOET MAKKELIJK, SNEL EN BETROUWBAAR TE BEREKENEN ZIJN

Het hele punt in het voorbeeld was om tijd en resources te besparen. Daarnaast is het natuurlijk prettig als de checksum altijd dezelfde waarde geeft voor dezelfde data.

2) DE CHECKSUM MOET VERANDEREN ALS ER OOK MAAR ÉÉN BIT VAN HET PLAATJE
ANDERS IS

Aangezien de checksum in dit geval minder data bevat dan het plaatje, is het niet te voorkomen dat er een ander plaatje is dat dezelfde checksum heeft. We spreken in zo’n geval van een collision (botsing). Er kunnen echter wel eisen gesteld worden aan het algoritme, om ervoor te zorgen dat de kans dat een collision ons tot een onjuiste conclusie leidt zo klein mogelijk is en zo toevallig mogelijk is.

  • Alle mogelijke checksums van alle mogelijke plaatjes zijn homogeen verdeeld, iedere checksum komt even vaak voor. Dit maakt de statistische kans dat we met een collision te maken krijgen zo klein mogelijk;
  • Theoretisch gezien zouden we een heel klein plaatje kunnen versturen dat zelfs nog kleiner is dan de checksum, in zo’n geval zou een collision nooit voor mogen komen ten opzichte van een andere plaatjes met gelijke grootte;
  • Een minieme wijziging aan het plaatje moet altijd tot een andere checksum leiden, anders zouden we nooit vast kunnen stellen dat het plaatje niet helemaal goed is overgekomen;

3) VOORSPELBARE OF VASTE LENGTE

De checksum moet een voorspelbare/vaste lengte hebben. Zo kan de ontvanger constateren dat het de hele checksum binnen heeft. Verder is het technisch gezien makkelijker om met iets van een vaste lengte te werken dan met iets van een variabele lengte.

Zie de afbeelding hierboven voor een voorbeeld van een simpel Checksum algoritme.

Als 77 over de lijn wordt gestuurd na het woord “nederland”, kan de ontvanger constateren of de ontvangst goed is. Maar is dit een goed checksum algoritme?

  • Makkelijk en snel is het wel;
  • Als er één letter veranderd, komt er een ander getal uit het algoritme, maar als er een tweede letter veranderd wordt, zou het kunnen dat het resultaat weer 77 is, bijvoorbeeld “neaerlandg” heeft in dit geval ook een hash van 77.
    Sterker nog, de hashes zijn ook niet homogeen verdeeld, 0 zal nooit voorkomen en 1000 ook niet. Veel hashes zullen tussen de 50 en 100 zijn;
  • Een vaste lengte heeft deze methode zeker niet. Als we ons beperken tot landnamen zal de lengte variëren tussen twee en drie cijfers, voor hele stukken tekst kan het van alles zijn;

Het getoonde checksum algoritme is dus niet heel goed, maar het illustreert wel wat een checksum in essentie is.

Waar een checksum prima werkt als maatregel tegen onopzettelijke transmissie en opslagfouten, werkt het niet noodzakelijk goed als middel tegen opzettelijke veranderingen in
de data.

Dit is bijvoorbeeld relevant als het plaatje dat verstuurd wordt bijvoorbeeld op een paspoort geplaatst moet worden. Het moet namelijk wel jouw foto zijn en niet die van een ander die met jouw paspoort op reis wil.

Om dit te bereiken is er een speciale klasse van checksum algoritmes, de hash. Ons voorbeeld is een hele slechte hash functie; uit 77 kan het aantal letters ongeveer bepaald
worden. Dat maakt het maken van een woord dat hetzelfde aantal letters heeft en dezelfde hash een peuleschil.

Daarom moeten we nog een extra eis toevoegen voor een hashing algoritme:

4) MOEILIJK TERUG TE HERLEIDEN

Op basis van de hash waarde moet zo min mogelijk informatie vrijgegeven worden over de oorspronkelijke data. Het moet zo goed als onmogelijk zijn om op een korte tijdschaal vanuit een gegeven hash waarde alternatieven (collisions) voor de oorspronkelijke data te berekenen.

Stel dat je een setje overschrijvingen klaar hebt voor de bank. Deze beveilig je dan door de hash te berekenen en die mee te sturen met de overschrijvingen. Zo kan de bank constateren dat ze de informatie in goede orde hebben ontvangen en dat niemand de gegevens heeft aangepast.

Normaal gesproken zijn hash algoritmes openbaar. Een aanvaller zou dus kunnen proberen om een combinatie van overschrijvingen te vinden dat tot dezelfde hash leidt (een collision). Als hij daarna de betreffende rekeningnummers aanvraagt zou hij je kunnen beroven.

Hash waardes hebben typisch een lengte van 128 of 256 bits. Bij een goed algoritme moet een aanvaller het gemiddeld een 1 met 39 nullen keer proberen, totdat hij een combinatie heeft met dezelfde hash waarde. Met 1000 pogingen per seconde is dat nog altijd meer dan een 1 met 27 nullen in jaren. Ter vergelijking, de leeftijd
van het Heelal is iets met 10 nullen in jaren.

Bij het hashen kan een extra voorziening getroffen worden om het breken van de hash te bemoeilijken. De hash kan “gesalt” worden. Aan de te hashen data, wordt extra data toegevoegd in de vorm van een al dan niet geheim wachtwoord. We spreken dan van een
“salted hash”. In de volgende Blog zal uitgelegd worden hoe het “Salt” helpt bij de bescherming van de gegevens.

Een ander toepassingsgebied voor hashes is de opslag van wachtwoorden en pincodes. Door de hash van een wachtwoord of pincode op te slaan kan een applicatie verifiëren dat de gebruiker het goede wachtwoord heeft ingevoerd zonder het wachtwoord zelf op te slaan (door de invoer opnieuw te “hashen”).

Als de database met hashes om de een of andere reden per ongeluk uitlekt, dan liggen de wachtwoorden niet direct op straat. Hopelijk heeft de eigenaar van de site wel lange en salted hashes gebruikt.

“STAY TUNED” VOOR HET VOLGENDE DEEL VAN DEZE BLOGREEKS: “CRACKING THE HASH”

BEHANDELDE BEGRIPPEN

  • Algoritme: Manier van berekenen.
  • Checksum: Controlegetal, berekend over een blok data met als doel het vaststellen van een foutloze overdracht van gegevens. Een voorbeeld van een checksum algoritme is de Cyclic Redundancy Check (CRC).
  • Collision: Wanneer twee verschillende blokken data dezelfde hash of checksum opleveren.
  • Hash: Controlegetal, berekend over een blok data, met als doel het op een veilige manier kunnen vaststellen van de integriteit van de data. Voorbeelden van veilige hash Algoritmes: SHA-2en SHA-3. hash algoritmes die vermeden moeten worden: MD5, SHA-0 en SHA-1.
  • Salted Hash: Het toevoegen van extra data aan het datablok waarover de hash berekend wordt, met als doel het terug herleiden van de hash naar de oorspronkelijke data moeilijker te maken.
Close Menu