Hoe groot is de kans dat een md5 checksum niet uniek is?

[sebas]

Ik Zat net mijn brakke code door te spitten en ben erachter gekomen dat ik een fout heb zitten in de manier waarop ik een sessionID bereken. Het is verder geen probleem, staat alleen een beetje suf als je weet waar het over gaat. Maar het heeft me wel eventjes aan het denken gezet.

Eenvoudig uitgedrukt plak ik twee strings aan elkaar, te weten IP en mktime en maak hier vervolgens een md5 checksum van, produceert een aardig ingewikkeld eruitziende tekenreeks, maar naar mijn weten niet per definitie altijd een andere. Dus het kan gebeuren dat ik twee keer dezelfde sessionID krijg.

Wat ik me nu afvroeg is hoe ik de kans kan berekenen die ik maak dat ik twee keer hetzelfde sessionID tegenkom. Ik schat die kans al erg klein in,. maar ik wil dus wel weten hoe klein precies. En hoe groot is de kans dat als een van de twee constant is (bijvoorbeeld als ik dezelfde mktime of IP gebruik)? (Zeker bij mktime kan ik me voorstellen dat dit een aardig ingewikkelde berekening kan worden gezien het feit dat het een lineaire functie is.)

Ik ben zeker geen wiskunde genie (blijkt wel), daarom kan ik ook niet echt de manier verzinnen hoe ik het zelf uit kan rekenen. Sterker nog, ik weet niet echt waar ik moet beginnen.

Iemand die me hiermee kan helpen? Het is meer een theoretisch probleem dan een praktische vraag. Toen ik het op de chat vroeg was meteen iedereen stil.

[Ericston]

Behalve ik.

1701 <Ericston> 32 chars (0-f)
1701 <Ericston> 16 bytes
1701 <Ericston> 2^8^16 is het aantal mogelijkheden
1701 <Ericston> dan gebruikt ie misschien niet alle mogelijkheden...
1702 <Ericston> maar meestal als je met mdcrack een digest van minder dan 10 chars bruteforcet
1702 <Ericston> + dan krijg je wel de originele string terug ipv een andere mogelijkheid

PHP:

$techposts++;

[Verwijderd]

Hmm, de kans zal wel heel erg klein zijn, maar het is mogelijk dat er 'ooit' 2 dezelfde sessionID's zijn, dit kan dan aan 2 dingen liggen:

1. werd ingelogd via een anonieme proxy en precies op dezelfde tijd (Zal waarschijnlijk niet gebeuren, maar zou kunnen)

2. Het resultaat van md5 encryptie is hetzelfde als een ander resultaat (deze kans zal iets groter zijn)

Het zou uit gerekend kunnen worden, maar hoe je dit precies moet dien weet ik zo ook niet precies, dan zou je precies moeten weten hoe de md5 encryptie inelkaar zit

[sebas]

Hmm. correct me if I'm wrong maareeeuh ...

Je houdt volgens mij geen rekening met het lineaire charachter van mktime in je berekening, de eerste 15 chars zijn ook niet 0-f maar ahw. ([1-255].) min de private ranges die er dus per definitie niet in kunnen komen.

[ Voor 0% gewijzigd door sebas op 25-10-2002 17:27 . Reden: 'niet' vergeten :o ]

[drm]

Ik denk dat je het anders moet zien. Je hebt X aantal combinaties van md5 checksums. Theoretisch zou bij X +1 logins dan 1 md5 iig 2x langsgekomen moeten zijn, en met kansberekening kom je op nog minder uit, waarschijnlijk.

Dan moet je met dit gegeven het probleem downpinnen met het idee in je achterhoofd dat de checksum meerdere malen voor kan komen, bij meerdere logins. Theoretisch zou dit dus iedere random login na elkaar kunnen zijn. De logins zijn random, omdat de user op elk random moment in kan loggen. Kortom, je hebt een random factor in je berekening, en kun je dus nooit garanderen dat 2 sessieID's gebaseerd op minimaal 1 random factor nooit identiek kunnen zijn.

Je hebt dus 2 mogelijkheden:

• De random factor elimineren
• De uniekheid (?) van een sessieID na de berekening garanderen door te checken of hij inderdaad uniek is

Die eerste lijkt mij onbegonnen werk, dus suc6 met de 2^e
_{</praktische-denkgeest>}

[Soultaker]

Het doel van een hash functie, is (stom gezegd) een zo willekeurig mogelijk getal genereren. Een 128 bytes hash als MD5 genereert dus getallen tussen 1 en 2^128. Nu zijn die niet helemaal willekeurig, maar aangenomen dat MD5 een redelijk goede hash functie is, dan komt het wel in de buurt. De kans dat twee waarden overeenkomen is dus ten minste 1 op 340282366920938463463374607431768211456, maar zelfs als 't een factor miljard slechter is, is die kans nog steeds praktisch nihil.

[Ericston]

Je moet dus even berekenen hoe groot de kans is dat uit zo'n 15000 sessies (het aantal sessies dat tegelijk plaats zou kunnen vinden, volgens sebas) er 2 dezelfde waarde hebben uit het bereik [0,256^16].

Dit is vergelijkbaar met de vraag hoeveel mensen er uit een groep van 26 personen op dezelfde dag jarig is. Dit was in 2000 een vraag voor de nationale wetenschaps quiz. Het antwoord is dit:

code:

# wat is de kans dat 2 mensen niet op dezelfde dag jarig zijn
365 / 365 # 1e persoon mag uit alle dagen kiezen
*
364 / 365 # 2e persoon mag uit 364 dagen kiezen
*
# etc
*
339 / 365 # laatste persoon mag uit nog maar 339 dagen kiezen

# het antwoord op de vraag is dus 1 - het antwoord uit de voorgaande berekening
1-0,4 = 0,6

Dus...

code:

# gesteld dat...
b = 256 ^ 16
i = 15000

1 - ((b - 1) / b) * ((b - 2) / b) * ... * ((b - i) / b)

Dus...

C++:

#include <iostream>

using namespace std;

int main() {
    double d = 3.4028236692093846346337460743177e38, i = 15000.0, a = 1.0;

    for ( int j = 1; j <= i; j++ )
        a *= (d-j)/d;
    
    a = 1 - a;

    cout << a << endl;  // drukt 0 af
    
    return 0;
}

Dus je hoeft je niet veel zorgen te maken. Enige fout zou kunnen zijn dat ik gebruik maak van de theoretische hoeveelheid aan md5 hashes en er vanuit ga dat al die hashes even vaak voorkomen.

[zoepercavia]

ik citeer van de website:

[The MD5 algorithm] takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. It is conjectured that it is computationally infeasible to produce two messages having the same message digest, or to produce any message having a given prespecified target message digest. The MD5 algorithm is intended for digital signature applications, where a large file must be "compressed" in a secure manner before being encrypted with a private (secret) key under a public-key cryptosystem such as RSA.

ze gaan er dus vanuit dat het vrijwel onmogelijk is. Overigens wel leuk

It is conjectured that the difficulty of coming up with two messages
having the same message digest is on the order of 2^64 operations,
and that the difficulty of coming up with any message having a given
message digest is on the order of 2^128 operations.

Hacken is dus vrijwel onmogelijk

[Ericston]

zoepercavia schreef op 25 oktober 2002 @ 18:08:
[...]

Hacken is dus vrijwel onmogelijk

Passwords van minder dan 8 karakters zijn nog steeds binnen afzienbare tijd te bruteforcen.

[.oisyn]

noem me maar lomp, maar waarom zou je een MD5 hash (128 bits) berekenen als je gegevens minder dan 128 bits zijn (ip adres = 32 bits, timestamp = 64 bits, samen 96 bits), als je daardoor het nodige risico loopt dat er wel eens 2 hashes hetzelfde zouden kunnen zijn

[Eskimootje]

Kunnen we geen eigen 'DPC'/DC project starten waarmee we een message maken die hashen en vervolgens een code gaan verzinnen die precies gelijk is. Dit kost geen internet breedte totdat de juiste code is gevonden. Of bestaat zoiets al??

[Verwijderd]

Ericston schreef op 25 oktober 2002 @ 18:07:
cout << a << endl; // drukt 0 af

Hetgeen dus alleen bewijst dat een double niet genoeg precisie heeft om dit soort waardes te berekenen Er kan nooit 0 uit deze berekening komen. Toegegeven, de kans is belachelijk klein, maar niet 0.

Verder legt Soultaker prima uit dat MD5 goed genoeg is om over die beperkte input message (ip + tijd) quasi-random 128-bits te genereren en dan is de kans zoals al meermaals gezegd gewoon 1 / 2¹²⁸.

Mocht de input message naar je gevoel te kort zijn, dan plak je er gewoon nog een aantal random bytes achter, dat maakt de MD5 key willekeuriger. Je moet dus geen randomness elimineren, maar de input meer random en langer maken.

[Ericston]

Verwijderd schreef op 25 oktober 2002 @ 18:43:
[...]

Hetgeen dus alleen bewijst dat een double niet genoeg precisie heeft om dit soort waardes te berekenen Er kan nooit 0 uit deze berekening komen. Toegegeven, de kans is belachelijk klein, maar niet 0.

[...]

Er kan wel 0 uitkomen, maar in dat geval is het aantal aanwezige sessies gelijk aan 0.
Ik vind dit een beetje een mierenneuk reply aangezien ik helemaal nergens beweer dat de daadwerkelijke kans kleiner is dan gelijk is aan 0. Je hoeft mij niet te vertellen dat een double dan niet genoeg precision heeft hoor.

1808 <Ericston> het valt iig niet meer binnen de precisie van een vc++ double
1808 <Ericston> dat is _klein_

Verder zei sebas al dat het meer theoretisch dan praktisch was, dan mag ik toch wel even mijn C++ skills *kuch* showen?

[eamelink]

drm schreef op 25 oktober 2002 @ 17:30:
Je hebt dus 2 mogelijkheden:

• De random factor elimineren
• De uniekheid (?) van een sessieID na de berekening garanderen door te checken of hij inderdaad uniek is

Die eerste lijkt mij onbegonnen werk, dus suc6 met de 2^e
_{</praktische-denkgeest>}

De eerste is opzich wel te doen hoor, als jij gewoon een countertje laat lopen, en dat getalletje aan het ip-adres plakt, heb je nooit dezelfde string die je gaat hashen. Je kan dan wel weer problemen krijgen dat mensen je strings kunnen gaan raden, alhoewel dat weer te verhelpen is door er een geheime string aan te plakken.

Die 2e is inderdaad veel gemakkelijker. Sla je sessie-ids op, en als hij al bestaat, waag je gewoon nog een poging ( de microtime is dan alweer wat verder, dus, geen probleem )

[eamelink]

.oisyn schreef op 25 oktober 2002 @ 18:20:
noem me maar lomp, maar waarom zou je een MD5 hash (128 bits) berekenen als je gegevens minder dan 128 bits zijn (ip adres = 32 bits, timestamp = 64 bits, samen 96 bits), als je daardoor het nodige risico loopt dat er wel eens 2 hashes hetzelfde zouden kunnen zijn

Dat is niet zo heel lomp hoor Als jij in je cookie iets leest wat eruit ziet als een ip + timestamp, dan is het véél gemakkelijker om sessions te hijacken. Bij zoiets als een md5 helemaal niet, je hebt geen idee waarvan die getrokken is.

[Verwijderd]

Als je ze iets meer random moet maken, kan je ook een random nr adden dus ip+timestamp+random nr

dan moeten ze via dezelfde proxie, op de zelfde tijd ook nog eens hetzelfde random nr hebben.

[Infinitive]

Heeft PHP daar niet:

PHP:

uniqueID()

voor?

[Orphix]

Verwijderd schreef op 25 oktober 2002 @ 20:21:
Als je ze iets meer random moet maken, kan je ook een random nr adden dus ip+timestamp+random nr

dan moeten ze via dezelfde proxie, op de zelfde tijd ook nog eens hetzelfde random nr hebben.

Maar wie zegt dat een ander ip met een ander random nr niet dezelfde hash oplevert??
Oftewel, maakt het meer 'random' maken van je source string iets uit voor de kans op een dubbele hash?

[Soultaker]

Orphix schreef op 26 oktober 2002 @ 01:44:
Maar wie zegt dat een ander ip met een ander random nr niet dezelfde hash oplevert??
Oftewel, maakt het meer 'random' maken van je source string iets uit voor de kans op een dubbele hash?

Waarschijnlijk niet of heel weinig. Waar je wel voor moet zorgen, natuurlijk, is dat het niet kan voorkomen dat de invoer van de hashfunctie hetzelfde is, want dan is de uitvoer dat natuurlijk ook. Daar kan het toevoegen van een random component wel bij helpen, mits je 'm tussendoor niet opnieuw seed met iets als de huidige tijd.

[martinvw]

Infinitive schreef op 25 oktober 2002 @ 20:53:
Heeft PHP daar niet:

PHP:

uniqueID()

voor?

neej:

PHP:

string uniqid ( string prefix [, bool lcg])

http://www.php.net/manual/en/function.uniqid.php

[Glimi]

Volgens mij was MD5 zo ontworpen dat een kleine verandering in de input een relatief groot verschil in de output geeft.

Dat zou dus betekenen dat in een bepaalde tijdsduur waarin het sessieid waardevol is (neem even 1 uur, als iemand 1 uur op uw website ronddoolt) is de input helemaal niet zo ontzettend verschillend. Zoals oisyn meldt worden 64 bits gebruikt voor de tijd. Hiervan zullen in een uur een groot aantal bits gelijk blijven. Daarom blijft de input voor een groot deel gelijk.

Hierdoor kun je volgens mij (sterk vereenvoudigd) redeneren dat de kans dat een MD5 binnen een uur gelijke output bij verschillende input geeft gelijk is nagenoeg 0 is. Een getal kan ik niet geven aangezien ik een ramp in kansberekening ben

[Verwijderd]

Hallo,

Ik ben dus geen PHP-kenner, maar als ik het goed heb, wordt de sessieID gebruikt om te checken of een gebruiker de zelfde is als daarnet.

Is het niet veel handiger om deze op te splitsen in twee delen:
sessieID (gewoon een long die steeds eentje optelt => unique waardes
sessieKey (De randome tekenreeks die voor authenticatie wordt gebruikt)

Cookie lezen is dan wel makkelijker. Maar, je kunt voor wat hijack protectie natuurlijk wel 't ip checken. (maar dat werkt dus weer niet bij proxy's)

[Verwijderd]

Ericston schreef op 25 oktober 2002 @ 18:11:
[...]

Passwords van minder dan 8 karakters zijn nog steeds binnen afzienbare tijd te bruteforcen.

Klopt

[Verwijderd]

Verwijderd schreef op 26 oktober 2002 @ 15:22:
Klopt

Een MD5 sum is altijd 128 bits, ongeacht de lengte van de message die je codeert. Je kunt dus onmogelijk weten of je te hacken password 1 dan wel 100 tekens lang is. Je kunt dan beter alle 2¹²⁸ mogelijke MD5 sums proberen. Good luck...

[eamelink]

Verwijderd schreef op 26 oktober 2002 @ 19:17:
Een MD5 sum is altijd 128 bits, ongeacht de lengte van de message die je codeert. Je kunt dus onmogelijk weten of je te hacken password 1 dan wel 100 tekens lang is.

Nou, ik kan bij de meeste passwords wel raden dat het aantal tekens tussen de 5 en 12 ligt ongeveer.

Als je dan gaat kijken welk gedeelte van de passwords 8 of minder tekens is, dan heb je er al een hele hoop te pakken. Dus als je een hele trits met MD5's van passwords te pakken hebt, zeg bijvoorbeeld de GoT database, en je gaat lekker random strings lopen hashen, dan heb er er gegarandeerd een heleboel gevonden in heel weinig tijd. Daarom is MD5 eigenlijk niet zo geschikt voor passwords, omdat het gemaakt is om snél te zijn (Is wel zo handig om ISO's te controleren ).

Verwijderd schreef op 26 oktober 2002 @ 19:17:
Je kunt dan beter alle 2¹²⁸ mogelijke MD5 sums proberen. Good luck...

Euhhhh, hoe wil je dat gaan doen? Je hebt een string, en je moet maar zien wat voor hash eruit komt. Voordát je bij álle md5 hashes een string hebt gevonden, heb je er al véééééééél meer moeten proberen dan 2^128

Maar we dwalen een beetje af, dit heeft weer zo weinig met het genereren van niet te raden sessionID's te maken

[edit]

die je codeert.

Je codeert niets, je hasht iets. Dat is nogal wat anders Je kán een MD5 niet 'decoderen' of zoiets, hooguit een string vinden die dit als hash oplevert. Dat is ook niet zo moeilijk hoor, want er zijn oneindig veel strings die dit als hash opleveren

[ Voor 0% gewijzigd door eamelink op 26-10-2002 22:18 . Reden: nog 1 dingetje ]

[vinnux]

Al dat gezeur over MD5
Er zijn in totaal 2^128 verschillende hashes. Als je naar het algoritme kijkt van MD5 kun je al snel concluderen dat de hash van x tekens (kweet niet meer hoeveel) altijd UNIEK is.
Ik neem aan dat je strings niet zo heel lang zullen zijn, dus geen MD5 problemen meer.
Als je dan oom de microtime opvraagt dan kun je met zekerheid zeggen dat je sessie id uniek is.

[Verwijderd]

Heh, voeg gewoon nog een random nummer toe met rand();

bv.
$sessie_id=$ip+time()+rand();
$sessie_id=md5($sessie_id);

[Verwijderd]

eamelink schreef op 26 oktober 2002 @ 22:15:
Euhhhh, hoe wil je dat gaan doen? Je hebt een string, en je moet maar zien wat voor hash eruit komt. Voordát je bij álle md5 hashes een string hebt gevonden, heb je er al véééééééél meer moeten proberen dan 2^128

Ik wil helemaal geen strings genereren, want dat is zoals ik al gezegd heb veel te langzaam. Dan kun je beter een 16 bytes teller implementeren, op nul zetten en gewoon beginnen met incrementeren. Natuurlijk is dat net zo'n onbegonnen werk als die strings genereren; daarom wens ik good luck.

Zelfs al neem je aan dat er van die 2¹²⁸ mogelijke MD5 sums minder dan. 0.01% gegenereerd wordt door beperkingen op de ingevoerde passwords, dan zit je nog steeds met 2¹¹⁴ mogelijkheden! De relevantie mbt. ons MD5 verhaal is natuurlijk, dat hier niemand zich schijnt te realiseren hoe enorm groot dat getal 2¹²⁸ is.

Je codeert niets, je hasht iets. Dat is nogal wat anders Je kán een MD5 niet 'decoderen' of zoiets, hooguit een string vinden die dit als hash oplevert. Dat is ook niet zo moeilijk hoor, want er zijn oneindig veel strings die dit als hash opleveren

<mode insectenliefde>
Definitiegebeuzel. Om dat even op de spits te drijven is een MD5 eigenlijk ook geen hash maar een partiele som. Net zoals een CRC geen hash is. Je kunt wel een pariele som of binaire polynoom (crc) als hashing functie gebruiken.
</mode insectenliefde>

[Verwijderd]

als het nog niet genoeg is kan je je sessie id nog eens base64_encode doen.
dan dus:
$sessie_id=$ip+time()+rand();
$sessie_id=base64_encode(md5($sessie_id));

of nog beter, ipv time(), gebruik microtime()
(das dezelfde unix timestamp maar in micro seconden)

$sessie_id=$ip+microtime()+rand();
$sessie_id=base64_encode(md5($sessie_id));

nu kan je onmogelijk 2 dezelfde sessie ID's hebben.

[Soultaker]

Wat voegt dat toe? Als de uitvoer van je hashfunctie hetzelfde is, is je base64 codering ook weer hetzelfde.

[MacLinux]

Hoe groot is de kans van 50% dat 2 mensen WEL op dezelfde dag jarig zijn:

1,18 * wortel n = 1,18 * wortel 365 = ongeveer 22.

Vul voor n de waarde van het aantal mogelijkheden en je hebt de kans van 50% van dezelfde fingerprint.

[.oisyn]

eamelink schreef op 25 oktober 2002 @ 19:28:
[...]

Dat is niet zo heel lomp hoor Als jij in je cookie iets leest wat eruit ziet als een ip + timestamp, dan is het véél gemakkelijker om sessions te hijacken. Bij zoiets als een md5 helemaal niet, je hebt geen idee waarvan die getrokken is.

aan dat argument heb ik idd zitten denken voordat ik postte, maar het feit blijft dat de topicstarter zijn algoritme hier al heeft neergezet, dus het maakt niets meer uit (of je nou ip+adres als sessie gebruikt of met de hand de md5 hash daarover uitrekent)

Bovendien moet er altijd nog een controle zijn om te kijken of de sessie wel klopt... Anders zou iemand anders, door te proberen, zich voor kunnen doen als de persoon die op die sessie is ingelogd... het lijkt mij dus wel noodzaak om een extra 'sessiecode' oid in een cookie op te slaan

[eamelink]

.oisyn schreef op 27 oktober 2002 @ 17:02:

[...]


aan dat argument heb ik idd zitten denken voordat ik postte, maar het feit blijft dat de topicstarter zijn algoritme hier al heeft neergezet, dus het maakt niets meer uit (of je nou ip+adres als sessie gebruikt of met de hand de md5 hash daarover uitrekent)

Ja, alleen hij kan het heel gemakkelijk veranderen. Als hij overal de string 'hoi' toevoegt, voordat hij hasht, heb jij géén idee wat hij gedaan heeft. Zo is zijn algoritme toch redelijk veilig.

Bovendien moet er altijd nog een controle zijn om te kijken of de sessie wel klopt... Anders zou iemand anders, door te proberen, zich voor kunnen doen als de persoon die op die sessie is ingelogd... het lijkt mij dus wel noodzaak om een extra 'sessiecode' oid in een cookie op te slaan

In principe is dit natuurlijk niet nodig, als de sessionID maar niet te raden is. Of je nou 32 tekens session ID hebt, met een random security code van 10 tekens, of je hebt een sessionID van 42 tekens die niet logisch te beredeneren is, maakt voor de veiligheid niet uit, het eerste is hooguit wat omslachtiger

[Glimi]

Juist zijn we er uit dat het allemaal geen kont uitmaakt wat het sessieid is, als het maar random is en uniek is binnen het geldige tijdsbestek. Je kunt allemaal mooie algoritmes erop loslaten, maar veiligheid ben je toch kwijt als er een sniffer op hangt.

[drm]

eamelink:
Je codeert niets, je hasht iets. Dat is nogal wat anders Je kán een MD5 niet 'decoderen' of zoiets, hooguit een string vinden die dit als hash oplevert. Dat is ook niet zo moeilijk hoor, want er zijn oneindig veel strings die dit als hash opleveren

offtopic:
Als we dan toch bezig zijn met dingen op de spits te drijven

Da's wel leuk, maar binnen die redenering heb je (2^-128) * oneindig mogelijkheden die de juiste hash (partiele som ) opleveren, en (2¹²⁸ -1) *oneindig mogelijkheden die een niet-juiste hash opleveren. Dat ben je dan denk ik een beetje vergeten. 't Feit dat de eerste berekening oneindig oplevert, zegt nog helemaal niets

_{ook voor mij de disclaimer dat ik een kruk ben in kansberekening}

[.oisyn]

eamelink schreef op 27 oktober 2002 @ 22:17:
In principe is dit natuurlijk niet nodig, als de sessionID maar niet te raden is. Of je nou 32 tekens session ID hebt, met een random security code van 10 tekens, of je hebt een sessionID van 42 tekens die niet logisch te beredeneren is, maakt voor de veiligheid niet uit, het eerste is hooguit wat omslachtiger

tja ik zat op een of andere manier te denken dat de sessieID in de url meegegeven werd (koppiepeest gevoelig dus)... ik weet echter totaal niet hoe ik aan die gedachte kom, want die is nergens geopperd in deze topic

[eamelink]

.oisyn schreef op 28 oktober 2002 @ 14:18:

[...]


tja ik zat op een of andere manier te denken dat de sessieID in de url meegegeven werd (koppiepeest gevoelig dus)... ik weet echter totaal niet hoe ik aan die gedachte kom, want die is nergens geopperd in deze topic

Je kan sessionID's aan alle links meegeven natuurlijk, maar dat doe je meestal alleen als je geen koekie mag maken. Dan heeft een extra code in een koekie ook niet zoveel zin

Da's wel leuk, maar binnen die redenering heb je (2-128) * oneindig mogelijkheden die de juiste hash (partiele som ) opleveren, en (2128 -1) *oneindig mogelijkheden die een niet-juiste hash opleveren. Dat ben je dan denk ik een beetje vergeten. 't Feit dat de eerste berekening oneindig oplevert, zegt nog helemaal niets

Inderdaad Altijd leuk, dat rekenen met meer of minder oneindige oneindigen. Daarom vond ik deze smiley er goed bijpassen ->

Oneindig * 2^128 is inderdaad een heel stukje groter dan het aantal strings dat de juiste hash oplevert