Nederlandse wiskundige: 2 op 1000 rsa-keys zijn onveilig

De Nederlandse wiskundige Arjen Lenstra concludeert dat twee op de duizend publieke rsa-keys, die onder andere worden gebruikt voor https-versleuteling, onveilig zijn. Deze rsa-sleutels zijn op dezelfde priemfactor gebaseerd.

Een groep wiskundigen van de École Polytechnique Fédérale in het Zwitserse Lausanne, heeft een collectie van 7,1 miljoen 1024bit rsa-keys onder de loep genomen. Het team kwam erachter dat bijna 27.000 sleutels kwetsbaar waren omdat ze een of meer priemfactoren delen.

Zeker 12.720 keys bieden geen enkele beveiliging meer, claimen de onderzoekers in een document genaamd 'Ron was wrong, Whit is wright', omdat ze voor een groot deel uit een openbare bron afkomstig zijn en iedereen het werk van de wiskundigen kan herhalen. Lenstra en zijn collega's gebruikten onder andere data uit het EFF SSL Observatory. Dit project heeft tot doel om alle publiek beschikbare ssl-certificaten die te vinden zijn via ipv4 te downloaden en kwetsbaarheden en problemen bij de toepassing aan het licht te brengen. Ook 2048bit rsa en ElGamal, dat de basis voor pgp vormt, zijn onderzocht en ook hierbij deed de kwetsbaarheid zich voor.

De doublures zijn te wijten aan random number generators die blijkbaar toch niet volledig willekeurig genereren, maar een duidelijke oorzaak hiervoor konden de wetenschappers niet geven. De beveiliging van publieke sleutels staat of valt met het niet herhalen van willekeurige keuzes bij het genereren van de keys. De wiskundigen concluderen dat 99,8 procent van de sleutels veilig is. Dit lijkt genoeg maar zelfs een klein aantal onveilige keys kan grote gevolgen hebben aangezien een groot deel van het authenticatiesysteem van sites op de rsa-beveiliging berust.

Het team uit Zwitserland is nu bezig om samen met de EFF-websitebeheerders, certificatenautoriteiten en browsermakers in te lichten. "We hopen dat de bugs van de random number generators snel gevonden worden en gepatcht worden", aldus Dan Auerbach en Peter Eckerlsey van de EFF.

Reacties (73)

[ktf]

Dit is raar

met het niet herhalen van willekeurige keuzes

Herhaling kan net zo goed random zijn, zie hier. De kans is alleen klein, maar 10x achter elkaar 6 gooien met een zuivere dobbelsteen is ook mogelijk, en toch random.

[Reactie gewijzigd door ktf op 29 juli 2024 05:57]

[3dfx]

Herhaling kan net zo goed random zijn, zie hier.

Offtopic, maar daar schijnt ook een film van gemaakt te zijn

[Mammon]

Vind ik deze een stuk leuker/knapper/random.

[gertvdijk]

Ik kan me zo voorstellen dat een deel van de 2% al te verklaren is door bugs als deze:
DSA-1571-1 openssl -- predictable random number generator
Deze bug in Debian genereerde dubbele keys in sommige gevallen. Hoewel al deze kwetsbare keys snel geïdentificeerd kunnen worden is het denk ik best mogelijk dat veel legacy (niet-geupdatete) systemen gewoon doordraaien op oude gegenereerde keys.

[GekkePrutser]

Is er ook een tooltje waarmee je zelf je eigen keys kan checken?

[robvanwijk]

Vermoedelijk niet, in elk geval nog niet. Het zou veel te makkelijk zijn om daar keys van anderen (laten we zeggen, alle internetbankieren sites...) doorheen te halen. Zelfs als de uitkomst alleen maar is óf een key kwetsbaar is (en niet meteen de ontbinding erbij geeft), dan nog is die informatie veel te bruikbaar voor kwaadwillenden; dan weten ze waar ze hun aandacht op kunnen concentreren.
Stel, je weet dat de internetbankieren.eenofanderebank.nl een kwetsbaar certificaat heeft. Dan kun je proberen het hele Internet te spideren op zoek naar een andere site die een certificaat met (stom toevallig) dezelfde sleutel gebruikt. Normaal gesproken is dat zinloos, maar nu weet je dat er ergens een speld in de hooiberg ligt (normaal gesproken zie je alleen een hooiberg, weet jij veel of daar ergens een speld in ligt). En, computers zijn nou eenmaal uitstekend geschikt voor het nauwkeurig uitvoeren van heel veel, heel simpel werk. Zodra je ergens het suffe hobby-servertje hebt gevonden dat (zonder het zelf te weten) dezelfde key gebruikt als een of andere bank (waar de eigenaar vermoedelijk nog nooit van gehoord heeft), dan kun je daar inbreken (dat is allicht makkelijker dan rechtstreeks bij de bank zelf in te breken), de private key stelen en een MitM-aanval opzetten.

De EFF is al bezig om gericht de betrokken partijen in te lichten; als je nu nog moet beginnen dan is het erg onwaarschijnlijk dat het je gaat lukken om bovenstaande aanval uit te voeren voordat het probleem opgelost is. Van de andere kant, waarom zouden die onderzoekers het risico nemen? Maar misschien dat zo'n tooltje gemaakt gaat worden zodra alle "interessante" keys vervangen zijn...?

[GekkePrutser]

Ja, maar zodra zo'n tooltje er is kunnen de banken natuurlijk onmiddellijk zelf hun keys checken en indien nodig vervangen. Ik neem aan dat hun beveiligings mensen ook wel op de hoogte zijn van dit soort ontwikkelingen (zouden ze wel moeten zijn in elk geval).

Zij kunnen zo'n key toch sneller vervangen voordat kwaadwillenden zo'n 'hobbyservertje' gevonden hebben, en belangrijker, voor ze een man in the middle attack opgezet hebben want dat is ook niet bepaald simpel natuurlijk.

Ik snap dat ze betrokken partijen inlichten maar ze gaan natuurlijk een hoop sites niet vinden met hun spider (om maar niet te beginnen over intranet sites). Transparantie lijkt me in dit geval veel belangrijker.

[maussie95]

Maakt dit echt zoveel uit voor de beveiliging? En praktisch: Hoe gaan ze dit oplossen? Het lijkt me niet dat zo'n generator snel gepatched is.

[flamingworm]

je kunt en randomgenerator niet "patchen"; computers kunnen geen random nummers genereren, maar komen dicht in de buurt. Deze onvolmaaktheid zorgt voor deze kwetsbaarheid.

[Navi]

ik vraag me dan af wat wel echt random is, een mens? ik denk het niet?

[Hiub]

Dat is voor cryptography ook niet zo interessant. Het gaat erom dat het willekeurig genoeg is (om er geen patronen in te herkennen zodat je volgende uitkomsten kunt voorspellen).

En er zijn allerlei methoden om te meten hoe "willekeurig" de data is die je pseudo-random generator uitpoept, zie bijvoorbeeld http://en.wikipedia.org/wiki/Randomness_tests

[Soldaatje]

Dobbelstenen gooien.
Daarnaast zijn de reacties hier ook behoorlijk random.

[Reactie gewijzigd door Soldaatje op 29 juli 2024 05:57]

[Verwijderd]

In theorie kan je exact berekenen welk getal gegooid gaat worden. Alleen op quantum niveau heb je echt random, namelijk daadwerkelijk ONBEPAALD tot het gemeten wordt wordt.

[Martreides]

Ik weet niet precies hoe het zit, maar is het niet zo dat het wel mogelijk is om de kans op een bepaalde uitkomst te berekenen. Dan zou het niet volledig random zijn.

[robvanwijk]

Als je een experiment nauwkeurig genoeg omschrijft is het altijd mogelijk om de kans op elke uitkomst te berekenen.

Het punt is dat gooien met een dobbelsteen (ik gebruik even een zes-zijdige als voorbeeld, maar voor een D12 en D20 geldt hetzelfde principe ) gelijke kansen heeft op elke uitkomst, ofwel P(1) = P(2) = ... = P(6) = 1/6.
Ook is het cruciaal (maar makkelijk om te vergeten), dat elke worp volledig onafhankelijk moet zijn van de vorige. Met andere woorden, als ik net een 6 gegooid heb dan geldt voor de volgende worp nog steeds P(6) = 1/6. Een (psychologisch gezien) belangrijker voorbeeld is dat als je net vijf keer op rij een 6 gegooid hebt de kans dat dat "lukt" is erg klein, maar vroeg of laat gebeurt het, dat ook dan voor de volgende worp nog steeds P(6) = 1/6 blijft gelden.

Overigens, ik heb hier beschreven wat belangrijk is voor het bepalen van bitjes van een cryptografische sleutel (de kans op 0 of 1 moet 50/50 zijn). Wiskundig gezien is "wel of geen 6 gooien" net zo goed een random proces (met P(wel 6) = 1/6 en P(geen 6) = 5/6). Strikt genomen is zelfs "wel of geen 7 gooien", met kansen P(wel 7) = 0 en P(geen 7) = 1 een kansproces.
Ook het trekken van gekleurde knikkers uit een vaas (zonder ze terug te stoppen) is een kansproces, ook al zijn de verschillende trekkingen niet onafhankelijk (elke keer dat je een rode knikker trekt wordt de kans om nog een keer een rode knikker te trekken kleiner).

[ANW]

Natuurlijk is het mogelijk om de kans op een bepaalde uitkomst te berekenen. Dit heet (Tatarata!!) kansberekening. De kans dat je met een dobbelsteen een 5 gooit is exact 1/6. De KANS op een bepaalde uitkomst is exact te berekenen. De uitkomst zélf van de worp is volledig random.
Sterker nog, juist OMDAT het volledig random is werkt kansberekening.

[mystic101]

ONBEPAALD wil nog niet zeggen random!

[mwolting]

Als je onmogelijk kunt bepalen wat voor waarde afgegeven wordt zonder te meten en er geen enkele structuur in zit noem ik dat toch wel echt random.

[Monochrome]

De grote vraag is of de structuur echt niet bestaat, of gewoon nog onbekend is. Of echte, harde randomness in het universum bestaat hangt af van het feit of het universum deterministisch is. Gegeven absolute kennis van het universum, is het dan mogelijk om precies te weten hoe het universum er over 1 seconde uit zal zien? Zo ja, dan bestaat randomness niet.

Natuurlijk een puur hypotetische overweging, de enige simulatie die dit zou kunnen is van een complexiteit gelijk aan of groter dan het universum. En past hier dus per definitie niet in.

[BeerenburgCola]

Genereerd wel veel entropie zo'n discussie, misschien moet je de tijden nemen tussen de reacties en alleen de milliseconden nemen. Ruis Gegarandeerd!

[Torrentus]

Computers kunnen wel semi-random nummers maken, bijvoorbeeld door de uitvoer van een microfoon of webcam te betrekken bij het genereren van de nummers. Je zou de ruis die een microfoon opneemt m.i. toch wel 'willekeurig' kunnen noemen.

[QQ2]

Het probleem bij dit soort zaken is dat dat alleen werkt voor de salt niet de key zelf. De key moet gebaseerd zijn op een priem getal die moeten aan een aantal regels voldoen waardoor je ze niet zo maar kan opnemen. In plaats daar van moet je ze berekenen en dan kan je dus tot het zelfde getal komen.

Ander belangrijk aspect is dat microfoonruis niet willekeurig is. Het wordt veroorzaakt door de bouw van de hardware en dus kunnen twee exact iedentieke PC's bijv 2 laptops met een factory image, hetzelfde patroon gebruiken. Een meer gangbare procedure is om de tijd in ticks als input te gebruiken zodat je immer voorwaarts werkt. Combineer dat met iets waarvan de uniekheid is afgedwongen (bijv CPU code) en je komt een heel eind. Er zijn ook CPU's van bijv VIA die een echt random waarde kunnen genereren)

Blijkbaar is er een generator in omloop die het bovenstaande niet toepast waardoor collisions gecreeerd worden. Dat is idd link en ik ben benieuwd wie\welke het blijkt te zijn

[Verwijderd]

Het blijken vooral routers en firewalls te zijn die deze "zwakke" keys genereren.

Bron: https://freedom-to-tinker...-just-mind-your-ps-and-qs

[z.jeroen]

Het probleem bij dit soort zaken is dat dat alleen werkt voor de salt niet de key zelf. De key moet gebaseerd zijn op een priem getal die moeten aan een aantal regels voldoen waardoor je ze niet zo maar kan opnemen. In plaats daar van moet je ze berekenen en dan kan je dus tot het zelfde getal komen.

Berekenen? Hoe bereken jij een priemgetal (van honderden cijfers)? Men gebruikt juist een random number generator. Als volgt: de rng maakt een getal; men ckeckt of het een priemgetal is; als dat niet zo is begin je van voor. Dat je tot hetzelfde getal kan komen is inherent aan het gebruik van een rng. De kans is alleen erg klein.

Ah sorry ik zie nu dat jij dit ook ongeveer zei.

[Reactie gewijzigd door z.jeroen op 29 juli 2024 05:57]

[dragonfly28]

Berekenen misschien niet helemaal, maar er is wel aantal manieren dat erg dicht in de buurt komt. Mersenne priemgetallen bijv. 2^n-1, als n een priem is dan is de uitkomst waarschijnlijk ook een priem.
Het probleem zit em hier alleen in de waarschijnlijk, want er zijn al sinds circa 1600 al enkele uitzonderingen bekend die toch geen priem zijn.
Er staat me iets bij van een 14 jarige Zweedse jongen (?) die een paar jaar geleden nog een uitzondering voor een relatief kleine waarde van n die lange tijd gemist was.

Primorial primes is een andere manier, daar zit dan weer het probleem in dat je eerst twee priemgetallen moet hebben om te vermenigvuldigen :-P

[robvanwijk]

Je algemene idee klopt wel redelijk. Er zijn inderdaad constructies die met relatief grote kans een priemgetal produceren, of (ook nuttig) die altijd een getal met een speciale eigenschap (die eenvoudig testen op priem mogelijk maakt) opleveren. Maar je voorbeeld is gruwelijk slecht; hoewel men oorspronkelijk dacht dat (2^priem)-1 zelf ook altijd priem is, blijkt dit helemaal niet het geval te zijn.

Een ander probleem is dat ze vreselijk snel absurd groot worden. Als je een 2048 bit key wil maken dan heb je twee priemen van elk ongeveer 1024 bit nodig. (Met een nummer van 8 bit en eentje van 2040 krijg je ook wel een 2048 bit key, maar die is met trial-division heel snel te kraken.)

quote: http://en.wikipedia.org/wiki/Mersenne_prime

As of October 2009, 47 Mersenne primes are known.

Het lijstje staat ook gewoon op Wikipedia. Omdat er ongeveer 3 1/3 bit in een (decimaal) cijfer gaan en RSA keys op dit moment tussen de 1024 en 4096 bit zitten zijn de enige Mersenne priemen die je zou kunnen gebruiken 150 tot 650 cijfers lang. Daarvan zijn er 3...! (Zelfs als we het oprekken tot max 700 cijfers dan zijn het er maar 5.)

En dan komen we bij het belangrijkste, deze zou je eigenlijk in alle generators moeten blacklisten! Als jij een RSA key wil kraken, dan moet je zoeken naar alle priemen van ongeveer de goede lengte. Dat is ontzettend veel werk (de reden dat RSA veilig is). Je kunt meteen gaan brute-forcen, of je kunt even controleren of je slachtoffer (of in elk geval zijn key generator) ontzettend dom is en een lijstje van bekende priemgetallen van de juiste lengte trial-divisionen. Dat is trouwens ongeveer een van de problemen die het artikel noemt:

Zeker 12.720 keys bieden geen enkele beveiliging meer, claimen de onderzoekers in een document genaamd 'Ron was wrong, Whit is wright', omdat ze voor een groot deel uit een openbare bron afkomstig zijn

[mad_max234]

Als je antenne neem die gevoelig genoeg is zal die achtergrond ruis opvangen die is altijd random, dat is straling vanuit het heelal. Microfoon is waarschijnlijk niet gevoelig genoeg, maar TV antenne zeker wel.

[Oeroeg]

Ik heb wel eens begrepen dat computers de duur van de laatste toetsaanslag door een formule heen gooien om een willekeurig getal te berekenen.

[BeerenburgCola]

Sommige algoritmen verzamelen "entropie". Dit kunnen ze op verschillende manier doen.
ssh-keygen doet dit ook.

Linux man file RANDOM(4):

The random number generator gathers environmental noise from device drivers
and other sources into an entropy pool. The generator also keeps an estimate
of the number of bits of noise in the entropy pool. From this entropy pool
random numbers are created.

Dit zijn dus wel 'echte' random getallen.

[analog_]

100 binary random waardes die allemaal 1 zijn, zijn ook random, maar dat is ook een uitzonderlijk geval.

[Reactie gewijzigd door analog_ op 29 juli 2024 05:57]

[z.jeroen]

Net zo uitzonderlijk als ieder ander getal van 100 bits.

[Origin64]

Je kunt inderdaad geen willekeurige nummers genereren, computers zijn logische machines. Je kunt er wel een geigerteller op aansluiten en met de hoeveelheid opgevangen achtergrondstraling gaan rekenen. Dichterbij volledige willekeurigheid dan dat kunnen wij mensen niet komen.

[.oisyn]

Dichterbij volledige willekeurigheid dan dat kunnen wij mensen niet komen.

Logisch, want dat ís volledige willekeurigheid. Vergelijkbare bronnen van entropie zijn de spin- en polarisatierichting van resp. een electron en foton.

[FireDrunk]

Kunnen ze daar niet een USB dongle van maken dan? Heb je gelijk je RNG

[robvanwijk]

Ehm, dit werd tijden geleden al gedaan door Intel (maar die zijn er sindsdien mee gestopt) en wordt tegenwoordig gedaan door VIA: link.
Intel is trouwens bezig om in toekomstige processoren weer een hardware random generator op te nemen. (Ik dacht ergens gehoord te hebben dat het in Ivy Bridge of Sandy Bridge ofzo zat, maar kan zo snel geen bevestiging vinden.)

[Diablow]

Niet echt relevant, maar dan nog krijg je bijna dezelfde getallen. Als je een geigenteller neemt, en het interval tussen twee metingen wordt het al een stuk beter, als je ook nog een vaste bron hebt, wordt het nog beter, en om extra zeker te zijn kun je bijvoorbeeld ook niet de huidige tijd oid gebruiken.

[Jasper Janssen]

Ivy Bridge krijgt een *echte* RNG aan boord, die met quantum ruis echte randomheid kan genereren. Dit probleem gaat dus binnenkort uit de wereld geholpen worden.

[pieterdebie]

Computers kunnen ook wel "echte" random nummers genereren.

http://www.random.org/ biedt zelfs een echte random dienst aan (al sinds '98)

Check zeker de faq eens van die site om er wat dieper op in te gaan

Edit: @hieronder, ja als je zo voortgaat kan een computer natuurlijk alleen maar A+B, enz...

[Reactie gewijzigd door pieterdebie op 29 juli 2024 05:57]

[Jasper Janssen]

Nee, computers kunnen inherent *geen* random nummers genereren. Wat wel kan is een specifiek stukje extra hardware nemen dat (quantum) randomness genereert/opvangt. Dat kun je inbouwen in een PC, maar het is dan niet de compute unit die randomheid maakt.

[BeerenburgCola]

Het hangt helemaal af van je definitie van "random" af.
Huidige algoritmes verzamelen entropie van je computer systeem wat al een vorm van 'willekeurigheid' is en deze worden als salt gebruikt for pseudo random generatoren wat een zeer hoge vorm van "willekeurigheid" geeft.

Tenzij je wiskunde studeert en een strikt theoretische definitie gaat hanteren, zou je deze deze getallen ook als "pseudo" random getallen kunnen beschouwen, maar in de praktijk zijn deze "random" genoeg.

[psyBSD]

Tenzij je wiskunde studeert en een strikt theoretische definitie gaat hanteren, zou je deze deze getallen ook als "pseudo" random getallen kunnen beschouwen, maar in de praktijk zijn deze "random" genoeg.

Volgens de onderzoekers die het artikel hebben gepubliceerd waar hier naar wordt verwezen.. blijkbaar niet.

[BeerenburgCola]

Op dit moment blijkbaar niet random genoeg (o ja, daar ging het artikel om), maar dit sluit niet uit dat ze het niet kunnen, zoals Jasper beweerd.

Maar misschien dat het tijd word voor een hardware ruisgenerator.

[.oisyn]

Sorry maar die redenatie vind ik echt onzin. Als je dat stelt dan stel je dus ook dat een computer helemaal niet zelf kan rekenen. Het is specifieke hardware op basis van halfgeleiders die ervoor zorgt dat je transistors kunt maken die logische bewerkingen (zoals NOT en OR) kan doen.

En het klopt, met louter transistors kun je geen echte randomness produceren. Maar het zal niet al te lang meer duren (zeker deze eeuw) voordat je PC standaard met een quantum processing unit is uitgerust die weer een heel nieuw scala aan features mogelijk maakt.

[Reactie gewijzigd door .oisyn op 29 juli 2024 05:57]

[robvanwijk]

Maakt dit echt zoveel uit voor de beveiliging?

JA!! Cryptografische keys (net zoals passwords) zijn volledig afhankelijk van geheimhouding. (Bij public key crypto is er weliswaar een deel van de sleutel die openbaar wordt gemaakt, maar ook in dat geval is geheimhouding van de private key cruciaal.) Dit onderzoek beschrijft hoe je (in zeldzame gevallen, maar dan nog) een key kunt kraken.

En praktisch: Hoe gaan ze dit oplossen?

Kwetsbare keys vervangen, da's niet zo moeilijk. (Tenminste, niet als de keys door software gebruikt worden. Een andere reactie meldde dat deze kwetsbaarheid vooral optreedt bij routers en firewalls; in dat geval is patchen wat lastiger, maar nog steeds te doen.)
Edit: originele post van sithlord2, die (voor zover ik weet als eerste) hier melding van maakte.

Het lijkt me niet dat zo'n generator snel gepatched is.

Je hoeft de generator (voor een key die door software wordt gebruikt) ook helemaal niet te patchen: weggooien en een andere, goede, gebruiken kan ook. Voor die routers en firewalls is dat lastiger, want die gebruiken waarschijnlijk niet alleen kwetsbare keys maar genereren ze ook zelf, in dat geval zal je het apparaat moeten patchen, hetzij door de generator te patchen, hetzij door een andere generator erin te bouwen, maar hoe dan ook meer werk dan simpelweg een sleutel vervangen.

[Reactie gewijzigd door robvanwijk op 29 juli 2024 05:57]

[zvbhvb]

Dit project heeft tot doel om alle publiek beschikbare ssl-certificaten die te vinden zijn via ipv4 te downloaden en kwetsbaarheden en problemen bij de toepassing aan het licht te brengen

Kun je tijdens het genereren van een certificaat checken op doublures?

[Verwijderd]

Technisch gezien wel, als je een grote database hebt van alle public keys die al in omloop zijn (als de public key identiek is, is de private key ook identiek). Maar het zou enorm veel tijd in beslag nemen.

En er is ook het veiligheidsrisico dat deze databank wordt gebruikt in omgekeerde richting.

[z.jeroen]

Technisch gezien wel, als je een grote database hebt van alle public keys die al in omloop zijn (als de public key identiek is, is de private key ook identiek). Maar het zou enorm veel tijd in beslag nemen.

Dat valt toch best mee? Je hoeft slechts de modulo te vergelijken. Dit kan met een binary tree.

En er is ook het veiligheidsrisico dat deze databank wordt gebruikt in omgekeerde richting.

Klopt, het zou dus een zwarte doos moeten zijn.

[Pixeltje]

Toch slordig, nu dit bekend is zal er binnen de korte keren wel een manier zijn om ongeveer te voorspellen welke keys onveilig zijn.

[Matthijs Hoekstra]

Bij dit soort dingen moet ik altijd aan deze Dilbert denken
http://search.dilbert.com/comic/Random%20Number%20Generator

[BeerenburgCola]

Heeft niemand nog deze XKCD gepost ?
Bij deze dan:

http://xkcd.com/221/

[Verwijderd]

raar dat 2 op de duizend wordt gezegd, waarom niet 1 op 500?

[the_stickie]

99,8% veilig -> 0,2% onveilig = 2/1000 velig.
Dat is hetzelfde als 1/500

Het vreemdst is
"7,1 miljoen 1024bit rsa-keys onder de loep genomen. Het team kwam er achter dat bijna 27.000 kwetsbaar waren omdat ze een of meer priemfactoren delen": dit is bijna 0,4%!
Ik vraag me af waaromer0,2% kwetsbaar is maar wel als veilig beschouwd kan worden

[mindcrimemike]

Het antwoord op je vraag staat in de volgende zin van het artikel: "Zeker 12.720 keys bieden geen enkele beveiliging meer,....". Dat is de 0,2% lijkt me.

[.oisyn]

99,8% veilig -> 0,2% onveilig = 2/1000 velig.
Dat is hetzelfde als 1/500

Ja dat had je persoon waar je op reageert denk ik ook wel door. De vraag die hij stelde was waarom ze 2/1000 zeggen, en de breuk niet vereenvoudigen naar 1/500. "Omdat het hetzelfde is" is natuurlijk geen antwoord op de vraag.

@lol23: ik vermoed dat x / 10ⁿ veel mensen wat meer zegt dan 1 / y. Bij 500 valt het wel mee, maar iets als "1 op de 63" is voor veel mensen niet veelzeggend. Zet je dat om naar iets als procenten (1,58%) dan kunnen veel mensen er veel sneller een voorstelling van maken hoeveel het nou eigenlijk is.

[Gropah]

Omdat 2 op de duizend een psychologisch groter beeld heeft dan 1 op de 500. Zelfde reden waarom het altijd 99.95 is en niet 100 euro. Het doet kleiner aan.

[Pixeltje]

Omdat het makkelijker uit te drukken is in percentages? Wat maakt het nou uit, het is precies hetzelfde maar in het licht van de 7.2 miljoen onderzochte keys is je resultaat uitdrukken in duizendtallen wat mij betreft logischer.

[dezejongeman]

dat vond ik ook al.
if zouden ze bedoellen dat van de foutive 2 op de 1000 exact overeen komen door die rare priem dingne

[ADT_Phantom]

Op deze manier lijkt het erger dan dat het is.

Als iets willekeurig wordt bepaald kunnen toch ook dezelfde waardes getrokken worden. Willekeurig betekend toch 'in willekeurige volgorde'. Hierdoor kan je ook 2x achter elkaar hetzelfde getal krijgen. Het sluit niet uit dan 1 getal meerdere keren wordt getrokken.

[BeerenburgCola]

Zoveel op de honderd, zoveel op de duizend rekent makkelijker. Vooral als je moet vergelijken.
Anders krijg je dit:

0.01 = 1 op de 100
0.02 = 1 op de 50
0.03 = 1 op de 33⅓
0.04 = 1 op de 25
0.05 = 1 op de 20

Etc.

[CurlyMo]

Je bedoelt 0,2% is onveilig. 0.02% is 2 op de 10000.

[SniperGuy]

Is de code het echt helemaal random?
er zijn 1.000.000 combinaties mogelijk (6 cijfers), iedere minuut een nieuwe code gegeven en je doet dus 694,44 dagen voordat alle codes "op" zijn en een token gaat langer mee dan dat...

[Reactie gewijzigd door SniperGuy op 29 juli 2024 05:57]

[z.jeroen]

6 cijfers? Een 1024-bit sleutel heeft 300 cijfers en is een product van twee priemgetallen. Dat geeft iets meer mogelijkheden. Er zijn ongeveer 10^147 priemgetallen van 150 cijfers volgens de prime number theorem.