Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 62 reacties

De random number generator die in het openssl-pakket van Debian wordt gebruikt, blijkt sinds september 2006 voorspelbare 'willekeurige' getallen te leveren. Cryptografische sleutels zouden dientengevolge niet veilig zijn.

Door een verkeerde aanpassing van het openssl-pakket van Debian is een voorspelbare random number generator in het pakket geslopen. Een nieuwe versie van het openssl-pakket waarin de random number generator is verbeterd, is inmiddels beschikbaar in de repositories. Ook een handmatige installatie is uiteraard mogelijk. Het Debian-beveiligingsteam raadt aan alle sleutels die met openssl-versies beginnend met 0.9.8c-1 gegenereerd zijn, opnieuw aan te maken met de verbeterde random number generator.

De eerste versie van openssl met de gemankeerde random number generator werd in september 2006 voor het eerst in de unstable distributie van Debian gebruikt. Het pakket werd in de test- en ook de productieversie van Debian Etch toegepast; de stabiele oude distro Debian Sarge heeft het pakket in ongeschonden toestand aan boord. De sleutels die mogelijk zwakker zijn dan gewenst betreffen sleutels voor ssh, openvpn, dnssec, x.509-sleutelmateriaal en ssl- en tsl-sleutels. Naast Debian zijn ook distributies die van Debian afgeleid zijn, zoals de diverse Ubuntu-versies, mogelijk kwetsbaar. Ook zou het mogelijk zijn dat uit Debian geïmporteerde sleutels andere besturingssystemen kwetsbaar maken.

Randomnumber xkcd
Moderatie-faq Wijzig weergave

Reacties (62)

dat plaatje is brilliant! wel jammer van de fout, maar toch verwacht ik dat het snel wordt geupdate in alle repositories.
... verwacht ik dat het snel wordt geupdate in alle repositories.
Voor Debian 4.0 (aka Etch, de huidige stable release) zijn updated packages al beschikbaar in de security repositories.

Maar het probleem is dat keys die met de foute openssl gegenereerd zijn voorspelbaarheid bevatten, maar die keys worden niet vervangen als je de updated packages installeert. Dat kan ook niet zomaar, want andere machines kunnen voor authenticatie of idenfiticatie afhankelijk van die keys zijn, en dat kan problemen geven als die zomaar veranderen. (Een ietwat kromme vergelijking is dat de sloten van je huis automatisch vervangen worden zonder dat je een nieuwe sleutel hebt)

De Debian Security Advisory bevat gedetailleerdere informatie, waaronder een link naar deze Debian pagina waar de key rollover van populaire software beschreven zal worden (de pagina is nu nog leeg).

Voor SSH bijvoorbeeld (want dat zal de meeste mensen treffen) gaat dat ongeveer als volgt:

De SSH host keys worden gebruikt om te bewijzen dat je SSH client ook daadwerkelijk inlogt op de SSH server waarop je in wilde loggen. Als een aanvaller deze keys kan voorspellen/raden, en hij weet zich (netwerktechnisch) tussen je SSH client en server te wurmen, dan kan hij een man-in-the-middle attack uitvoeren.

De SSH host keys zijn te vinden in /etc/ssh/ssh_host_* . Je kunt ze met ls -l inspecteren, als ze ouder zijn dan 2006-09-17 dan zouden ze in orde moeten zijn (ervan uitgaande dat de datum op je systeem klopt(e), etc).

Je kan nieuwe SSH host keys genereren met de volgende commando's (na eventueel de oude keys te backuppen):

# ssh-keygen -N '' -t dsa -f /etc/ssh/ssh_host_dsa_key
# ssh-keygen -N '' -t rsa -f /etc/ssh/ssh_host_rsa_key

SSH clients die je computer met de nieuwe keys al kenden zullen vanaf dat moment (terecht) klagen dat de SSH host key veranderd is. Je zal de client dan wijs moeten maken dat dat echt de bedoeling is.

Voor de OpenSSH commandline client kan dat door de host te verwijderen uit ~/.ssh/known_hosts en daarna opnieuw proberen in te loggen. SSH zal dan zeggen dat hij die host nog niet kent (klopt, je hebt hem verwijderd) en vragen of je hem wil accepteren. Als je gecontroleerd hebt dat de key fingerprint hetzelfde is als de fingerprint die ssh-keygen uitspuugde, dan kun je "yes" antwoorden.

Vergeet, als je gebruik maakt van public key authentication ("passwordless login"), ook niet de keys in ~/.ssh van de client machine aan te pakken, en de client host te verwijderen uit de ~/.ssh/authorized_keys op de server machine.

(Als bovenstaand verhaal niet duidelijk genoeg was, dan kun je waarschijnlijk beter even wachten tot die key rollover pagina van Debian een verhaal voor SSH bevat.)

edit:
Er zijn nieuwe updates voor de ssh, openssh-server en openssh-client packages. Deze updates helpen met het bovenstaande key verhaal voor SSH. Als je de updates installeert, dan krijg je ook een blacklist van zwakke keys (nieuw package: openssh-blacklist) welke op de volgende manieren gebruikt wordt:
  • Tijdens installatie van de nieuwe updates wordt gecontroleerd of je SSH host keys (/etc/ssh/ssh_host_*) geblacklist zijn, en zo ja, dan zal de installer nieuwe host keys genereren.
  • Public key authentication ("passwordless login") vanaf andere machines wordt gecontroleerd tegen de blacklist en geweigerd als de public key in de blacklist voorkomt. Passwordless logins vanaf accounts met een zwakke SSH user key werken dus niet meer na het installeren van deze updates.
De Debian Security Advisory voor deze updates bevat gedetailleerdere informatie (waaronder ongeveer het hele SSH host key verhaal dat ik gisteravond hierboven heb geschreven).

Tot slot nog dit:
Als je apt-get of aptitude gebruikt om te updaten, dan kan het zijn dat hij openssh-server en openssh-client niet wil installeren omdat die op een extra package dependen (namelijk openssh-blacklist). Je krijgt dan iets a la "Kept back: openssh-client openssh-server".

In dat geval helpt het om dist-upgrade te doen in plaats van upgrade. Wat ook helpt is iets als apt-get install openssh-server doen, waarmee je duidelijk maakt dat je toch echt die nieuwe openssh-server wil, ook als dat openssh-blacklist meesleept. Wat ook kan is openssh-blacklist expliciet installeren en daarna nog eens upgrade doen.

edit2:
Meer leesvoer: http://wiki.debian.org/SSLkeys
Zo te zien bevatten de door de foute openssl gegenereerde keys maar een bit of 16 aan randomness, wat passwordless logins die deze keys gebruiken makkelijk te bruteforcen maakt. Het is dus zeer aan te raden om passwordless login setups goed te controleren. Keys verwijderen / opnieuw aanmaken, en vooral de ~/.ssh/authorized_keys op de doel-machines goed te inspecteren (of gelijk maar helemaal te verwijderen).

[Reactie gewijzigd door deadinspace op 14 mei 2008 16:08]

Het zou ook zeer netjes zijn als Tweakers ook een link terug naar xkcd had geplaatst (zoals gevraagd op de website van xkcd).
Kijk voor de grap eens in de ALT-tag, welke je als XKCD fan (?) niet onbekend mag zijn!
Voor de niet-XKCD fans, de clue zit in de Alt tags van de plaatjes :D
Wie had het laatst ook alweer over dat Windows 2000 zo lek was omdat daar de RNG niet bij deugde? :+.
Ik vind dit eerlijk gezegd nogal een verschil met die RNG van Windows 2000. Dit is Open Source, waarbij men doorgaans beweert dat de code juist zo goed is omdat iedereen het kan controleren en ernstige fouten dus snel naar voren komen. Nu blijkt dat dat dus lang niet altijd het geval is. Twee jaar is nu eenmaal niet bepaald snel.

Dit is echt een tegenslag voor Open Source wat mij betreft.
Waarom is dit een tegenslag voor open source? Als Debian closed-source was geweest was deze bug misschien wel helemaal niet, of veel later ontdekt. Je doet alsof open-source op de een of andere manier een wondermiddel tegen bugs is, terwijl het alternatief (closed source) waarschijnlijk net zo veel of meer bugs bevat, die veel minder snel aan het licht zullen komen.

Daarbij lijken de 2 bugs wel veel op elkaar maar is mij in ieder geval niet duidelijk hoe en hoe makkelijk ze exploitable zijn. Volgens mij werd het gevaar van de Windows RNG bug al zwaar overtrokken en zijn er geen bekende exploits, dit zou bij de Debian bug ook best zo kunnen zijn.

Last but not least betreft dit een aangepaste OpenSSL implementatie die *misschien* ook in Debian-afgeleiden zit, maar sowieso niet in *alle* open-source software die OpenSSL gebruikt.
Ik ben het eens met je constatering dat in een closed-source programma deze bug waarschijnlijk angstvallig geheim zou zijn gehouden.

Helaas is deze bug wel degelijk exploitable, en nog wel kinderlijk eenvoudig. Het is echt een ramp. En het probleem geldt voor alle software in Debian die gebruik maakt van openssl, wat zo ongeveer ieder netwerkpakket is.
OK. Bij deze wil ik jouw hier persoonlijk uitnodigen om op een productie Debian Etch systeem van ons een SSH key te kraken aangezien het kinderlijk eenvoudig is voor jouw. Ik wil er zelfs een beloning aan vast knopen. Ik heb er speciaal voor thuis een adres voor gemaakt (opensslbug@koivijver.eu en deze is werkzaam tot 16 mei)

Verder is er geen 'bug' die exploit kan worden. Laten we even SSH aanhouden. In dat geval moet jij moet namelijk een bestaande private key - waarvan de public key op de server bekend is- 'raden'. Dat raden van de key is enigsinds mogelijk door deze bug, maar de kans dat je daarbij ook nogeens de user (root login is uitgeschakeld) correct hebt acht ik vrij klein. Onze RSA keys zijn 2048 bits vanwege hun dominante posities in onze infrastructuur.

De ramp is dat deze issue volledig door werkt naar andere distro's. Stel dat Verisign debian gebruikt, dat betekend dat als hun uitgegeven certificaten een probleem hebben. Of wacht dat je van web of trust certificaten. Elk systeem dat werkt met 'authorized_keys' en daarop een debian key heeft is theoretisch vulnerable.

Het is dus niet zozeer de bug welke het grootste probleem vormt, maar juist de certificaten en keys welke ermee zijn gegenereerd.
leg eens uit hoe kinderlijk eenvoudig dat dan is? de pakketje's sniffen en proberen te decrypten met wat gegenereerde keys op een exploitable debian?
Het is inderdaad een tegenslag en dit geeft maar weer eens aan dat je altijd licht paranoia moet blijven wat security betreft.

Maar om het geheel even in perspectief te zien:
- de fout in de Windows 2000 RNG zit er 8 jaar in en wordt niet gepatcht.
- diezelfde bug zit ook al 7 jaar in Windows XP en is pas in Service Pack 3 gepatcht, een half jaar na het bekend worden
- de fout in de openssl RNG van Debian heeft er 2 jaar in gezeten en is direct gepatcht al gepatcht bij bekendwording / making.
edit:
@ Devon: je hebt gelijk ^^

[Reactie gewijzigd door lammert op 13 mei 2008 22:12]

Wie zegt dat hij meteen gepatcht is? Misschien is het al wel een tijdje stilgehouden?

Dat maak ik hier nergens op uit.
Bij Windows 2000 duurde het veel langer, dat was pas vorig jaar ofzo (=7/8 jaar). De graaft dus je eigen kuil
Ben ik het niet mee eens. Zijn punt is dat twee jaar een érg lange tijd is. Ja, 7 jaar is nog langer, maar dat maakt die 2 jaar niet ineens goed. Het gaat er helemaal niet om dat fouten sneller ontdekt zouden moeten worden. Het gaat erom dat het snel ontdekt wordt. En dat is niet gebeurd.

[Reactie gewijzigd door .oisyn op 13 mei 2008 17:55]

Nuancering: De Debian-update is na een dergelijke bug-vondst gemiddeld enkele uren later beschikbaar. Andere softwareschrijvers doen er soms weken/maanden over om de bug te fixen.
@Bloodshot

Heb jij toevallig data waaruit blijkt dat de kwaliteit van een bugfix omgekeerd evenredig is met de tijd die men spendeert aan het fixen? (Ik ben er mij van bewust dat onderzoeksdata uitwijst dat de beste programmeurs vaak sneller en beter fouten verbeteren. Zie bijvoorbeeld Code Complete 2 en The Mythical Man Month. Dit is echter niet de implicatie die jij maakt.)

Ik denk dat menig programmeur wel weet dat de "quick fix" bijna altijd het langste duurt :). Lees zeker eens Getting It Wrong - A Cautionary Tale van Michael Jackson.

Wat ik persoonlijk niet begrijp, is waarom men überhaupt getracht heeft om te experimenteren met een andere pseudo random number generator (PRNG). Goede PRNG bestaan al járen; Knuth wijdt er een heel hoofdstuk aan in The Art of Computer Programming (1969). De hele mathematische uitwerking die volgt, moet menig ontwikkelaar doen inzien dat het zelf ontwikkelen, of zelfs maar aanpassen, van een PRNG een taak is die men te allen tijde dient te vermijden.

[Reactie gewijzigd door Nick The Heazk op 14 mei 2008 00:04]

Wat ik persoonlijk niet begrijp, is waarom men überhaupt getracht heeft om te experimenteren met een andere pseudo random number generator (PRNG).
Het was niet de bedoeling om iets essentieels aan het algoritme te veranderen. Hij heeft alleen per ongeluk een regel teveel verwijderd. En er was een goede reden voor, omdat die regel iets doet wat normaal gesproken een doodzonde / beginnersfout is, namelijk het gebruiken van een ongeinitialiseerde variabele.
(voor niet programmeurs: Y = X + 1, zonder op te geven wat X is, is onzin).

In dit hele specifieke geval was het geen fout, de code is namelijk toch al bezig met willekeurige getallen te genereren. Gelukkig zijn er tools om dit soort programmeer fouten vinden. Helaas geven dat soort tools (Valgrind in dit geval) grote fouten op ieder programma dat openssl gebruikt, en dat zijn er nogal wat.

Daarom heeft de beheerder die regel(s) (na goedkeuring van de openssl ontwikkelaars) verwijderd.
...(na goedkeuring van de openssl ontwikkelaars)...
Heb je misschien een bron voor die bijzonder onwaarschijnlijke claim? Het is erg genoeg dat ze bij Debian een idioot met zijn vingers aan hun versie van openssl laten zitten, maar dat de ontwikkelaars van openssl zelf zo ver heen zijn gaat er bij mij dus echt niet in.
...(na goedkeuring van de openssl ontwikkelaars)...

Heb je misschien een bron voor die bijzonder onwaarschijnlijke claim? [...] maar dat de ontwikkelaars van openssl zelf zo ver heen zijn gaat er bij mij dus echt niet in.
Redelijk wat informatie over de toedracht is te vinden op http://wiki.debian.org/SSLkeys onder het kopje "Causes".

Kort samengevat, de Debian developer heeft die wijziging destijds wel aangekaart op de openssl-dev mailinglist en heeft daar een handvol instemmende (of in ieder geval niet afkeurende) reacties gekregen. Het probleem is echter dat dit een mailinglist is voor applicatie-ontwikkeling gebruik makend van openssl, niet een mailinglist over openssl-ontwikkeling.

Leesvoer:
Het gebruiken van een niet geinitialiseerde variabele klinkt mij dan nog steeds als een fout. Hoe kan je nu garandereren dat het gebruik van deze niet geinitialiseerde variabele een willekeurig getal oplevert?!? Ik ken de betreffende code niet, maar ik verwacht (en hoop) dat het iets anders in elkaar steekt!
Nuancering 2: Debian zal het geen ruk kunnen schelen of jouw applicatie server ineens klapt door hun bugfix, ze namelijk geen tijd genomen noch de mankracht om alle mogelijke implicaties te onderzoeken zoals wel van commercieele bedrijven wordt verwacht (let wel, ik zeg verwacht, niet dat het altijd naar behoren gebeurt)
Debian zal het geen ruk kunnen schelen of jouw applicatie server ineens klapt door hun bugfix, ze namelijk geen tijd genomen noch de mankracht om alle mogelijke implicaties te onderzoeken zoals wel van commercieele bedrijven wordt verwacht.
Pardon? Jij hebt echt nooit met Debian gewerkt, je hebt geen flauw benul waar je het over hebt... als er één distro het schoolvoorbeeld is van hoe je updates en patches moet testen dan is het wel Debian. Je onderschat duidelijk de efficiëntie van een community zoals die van Debian. Vergelijk nu jouw bewering "het zal Debian geen ruk kunnen schelen" eens met paragraaf 4 uit het hierboven reeds genoemde "Social Contract":
# Our priorities are our users and free software

We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environments.
En ja, ik heb ervaring met de Debian community support en menig OS bouwer (free en non-free) kan daar een puntje aan zuigen.

Over de patch zelf: het enige effect van deze patch is dat je een "meer random" SSH key krijgt, en bovendien pas op het moment dat je deze zelf aanmaakt. Als je applicatie daardoor crasht dan is er iets mis met je applicatie of je patchprocedure. Bovendien is het je eigen verantwoorlijkheid als sysadmin om elke patch voor een belangrijke applicatieserver te testen voordat je hem uitrolt.
edit:
Toevoeging: door de modulaire opbouw en transparantie van linux in het algemeen kost het testen van updates en patches nou eenmaal veel minder tijd.

[Reactie gewijzigd door lammert op 13 mei 2008 22:24]

Naar mijn idee worden niet alle security updates evengoed getest. Vorige week was er nog een cacti security update die cacti totaal onbruikbaar maakte. Op simpele kleine updates wordt veel minder getest. Bij de update van pdns-recursor van een paar weken terug heeft het een halve week geduurd voor de backport door het security team goedgekeurd was: de patch was dusdanig ingrijpend dat er eerst een code-audit overheen is geweest.
Overigens een mooi voorbeeld van transparantie: ik ben zowel op de debian-security als de debian-security-announce lijst aangemeld. De fout in de cacti update werd na een halfuur gemeld, nog een uur later was er een fixup package die de bug herstelde. Het is handig om even te wachten met security updates toepassen, als er iets mis is lees je dat dezelfde dag nog.
als er één distro het schoolvoorbeeld is van hoe je updates en patches moet testen dan is het wel Debian
Het lijkt medat dit prima als voorbeeld gebruikt kan worden hoe het niet moet. Niet als voorbeeld hoe je op correcte wijze patches en updates moet testen. Het staat 100% zeker vast dat het testen van updates en patches door Debian niet altijd correct werd uitgevoerd.

Voor de rest niets tegen Debian :)
als er één distro het schoolvoorbeeld is van hoe je updates en patches moet testen dan is het wel Debian
Het lijkt medat dit prima als voorbeeld gebruikt kan worden hoe het niet moet. Niet als voorbeeld hoe je op correcte wijze patches en updates moet testen. Het staat 100% zeker vast dat het testen van updates en patches door Debian niet altijd correct werd uitgevoerd.

Voor de rest niets tegen Debian :)
Het is een feit dat de test procedures bij Debian zeer degelijk zijn in vergelijking met anderen, daar doelde ik op met "schoolvoorbeeld". Ander feit is inderdaad dat er bij deze patch toch iets is mis gegaan. Maar ja, fouten zijn menselijk, daar is niets vreemds aan en het is ook niet uniek voor Debian, Microsoft, Apple of welk bedrijf dan ook.
Euh, juist vanwege de backports om software bijna binary compability te houden is deze fout ontstaan. De versies welke je krijg behoud je totdat je de distro upgrade naar de volgende stable distro. Het Debian team voert een soort dubbele 'diff' uit. Zij achterhalen welke onderdelen zijn aangepast vanwege een bug. Vervolgens gaan zij achterhalen hoe de wijziging aan de oudere versie kunnen doorvoeren zonder de functionaliteit te veranderen.

Het is dus onmogelijk dat als jij de stable apt sources gebruikt dat je server klapt. Dat is namelijk nog steeds de belangrijkste reden dat Debian voor servers wordt gebruikt. Stabiliteit. Bij een distro als Gentoo is de kans op klappen veel groter.

De backports van Debian hebben overigens wel een nadeel. Over het algemeen zijn de updates van Debian iets later dan van de andere distro's. Die gaat de laatste vanilla source gebruiken met daarover een aantal patches.
@Tijger over Nuancering 2:

Jij laat het nu over komen dat Debian geen commerciele divisie heeft? Hoe denk je dat zij bestaan. Juist door het leveren van support. De software mag dan wel gratis aangeboden worden. Wil je support hebben dan mag je daarvoor betalen. Dus even voor het gemak gezegd; Voor Linux distributeurs (je heb natuurlijk ook BSD etc..) valt er echt wel geld te verdienen. (zie ook Novell / Red-Hat )
@klaasbram: Debian heeft inderdaad geen commerciele divisie. Debian is op geen enkele wijze commercieel, dat is nou juist het belangrijkste kenmerk van Debian, ze zijn het schoolvoorbeeld van 'free as in speech', ánd 'beer', en dat wordt soms tot in het extreme doorgevoerd (problemen rond het Firefox-logo). Debian levert dan ook geen _commerciele_ support, alles gaat via de community. Wil je tóch commerciele support, dan moet je dat zoeken bij externe bedrijven. Debian heeft zijn bestaansrecht volledig te danken aan de vele duizenden vrijwillige ontwikkelaars, die een passie hebben voor de Debian-filosofie. Zie ook het Debian Social Contract.
Ja , het kan ze wel een ruk schelen. het zijn klanten, het gebruik van hun dristro houd ze op de markt.

Bovendien, 2 jaar geleden was het wel werkend, de bugfix zal waarschijnlijk niet ingrijpend zijn. En van 1 brak pakket crasht geen hele debian server, daarvoor moet je bij windows zijn. (Niet dat het daar altijd zo is, maar naar mijn mening wel veel vaker).
Nuancering 2: Debian zal het geen ruk kunnen schelen of jouw applicatie server ineens klapt door hun bugfix,
Als ze dat niet kon schelen waren ze allang al gekapt met het aanbieden van een gratis linux distro.
ze namelijk geen tijd genomen noch de mankracht om alle mogelijke implicaties te onderzoeken zoals wel van commercieele bedrijven wordt verwacht
Als je daarmee de indruk probeert te wekken dat MS' patches beter zijn omdat ze langer getest worden, try again. Het is al meerdere malen gebeurt dat een MS patch, die eerst een maand "getest" is, toch weer op zichzelf fouten blijkt te bevatten waardoor systemen ploffen (met IE-patches al meerdere malen). Heb zoiets nog nooit over debian patches gehoord. Die fixen de bug en vervolgens werkt het ook gewoon.
Het is belangrijker dat fouten snel hersteld worden eens ze ontdekt worden. Als alle fouten snel ontdekt worden maar het erg lang duurt voor er fixes zijn dan zit je met een veel groter probleem want dan schieten virusschrijvers in actie. Oh ja, en wat was nu weer het enige OS waar er een echt probleem is met virussen?
Het gaat erom dat het snel ontdekt wordt. En dat is niet gebeurd.
Ja en nee. Want naast het snel ontdekt worden van bugs is een snelle oplossing voor een probleem zeker zo belangrijk. Nou weet ik niet hoe lang de tijd is geweest voor er een patch kwam voor Windows2000, maar ik weet toch met redelijke zekerheid dat MS daar langer over heeft gedaan dan de Open Source community.

Daarnaast: dit is een probleem in Debian. En ja, het is een ernstig probleem.
Maar naast Debian zijn er nog een aantal andere distributies. Dus de mensen die nu gaan staan roepen dat heel Linux faalt moeten toch even nadenken of ze wel weten waar ze het over hebben...

bijvoorbeeld Tijger met zijn "nuancering 2": je weet gewoon niet waar je het over hebt als je zoiets post...
Snel of sneller.. dat is nogal relatief. Ik vind 2 jaar redelijk snel als het kennelijk normaal is dat zo'n bug normaal pas na 8 jaar wordt ontdekt. Snel en sneller zijn in dat geval overlappende begrippen.
Nu blijkt dat dat dus lang niet altijd het geval is. Twee jaar is nu eenmaal niet bepaald snel.
Dat is zeker waar. Debian patches worden waarschijnlijk een stuk minder goed/vaak bekeken dan OpenSSL zelf.
Hoe kan je eigenlijk uberhaupt een random number gen maken? Elke RNG die op een PC wordt gemaakt is sowieso voorspelbaar lijkt mij omdat hij altijd gebasseert zal zijn op een algoritme. Er zijn maar een paar dingen in de wereld die werkelijk random zijn.
Een RNG altijd een voorspelbaar algoritme, Het ene algoritme beter dan de andere. Maar om een werkelijk random iets krijgen zou je input van buitenaf kunnen gebruiken :)
Dan nog kun je iets programmeren dat "random genoeg" is.
Pak een paar geheugensegmenten en tel deze op. Pas vervolgens een XOR toe op de tijd (in miliseconden sinds 1-1-1970) en tel hier het aantal bytes in SWAP bij op.
Rond af op de gewenste lengte (random byte/word/etc.) en je bent klaar.
(Ik heb geen idee of dit reeel is, maar dit kwam spontaan bij me op. :9 )
Je kan echte random numbers maken door bijvoorbeeld een hash van een fysiek random verschijnsel te maken (bijvoorbeeld: een hash van een foto van een wolk of van een geluidsopname van lawaai in een kroeg).

Software based RNG's zijn eigenlijk allemaal Pseudo RNG's. De voorspelbaarheid van een goede Pseudo RNG is trouwens behoorlijk laag (in bovenstaand voorbeeld dus niet door een fout!). De tijd die je er voor nodig zou hebben overschrijdt de levensduur van het universum. Maar goed... misschien dat quantum computers die aanname weer van tafel gaan vegen?
Ja dat las ik dus ook al op wikipedia. Mensen die bijvoorbeeld lava lampen gebruiken of andere dingen waar duidelijk quantum mechanische effecten een rol spelen zoals de ruis in een transistor of in verval van deeltjes.

maar ik wist niet dat pseudo RNG zo betrouwbaar waren dat het zo lang zou duren om te kraken. Maarja aangezien computers ongeveer elke 3 jaar twee keer zo krachtig worden is dit ook niet echt een garantie voor de toekomst.

Interesant detail op de wiki die KompjoeFriek poste: Daar staat dat de Atari 8 bit family wel echte random getallen kon generen door de ruis uit een analoog circuit te meten. Misschien is dit een idee voor in de toekomst op moederborden. Op elk moederbord moet wel een analoog circuitje zitten wat ook niet al te moeilijk uitgelezen moet kunnen worden.
Is toch al op ieder moederbord te vinden? De geluidskaart.. gewoon een microfoon aan sluiten en de gebruiker een geluidje laten maken.
Ooit een artikel gezien over iemand die de filters van de ccd van zijn webcam afsloopte, om er vervolgens een isotoop uit een oude rookmelder op te plakken.

Op zijn cam beeld, zag hij dan af en toe een lichtpuntje wegschieten,
( Radioactief verval ) De cooordinaten hiervan werden vervolgens als "Random Seed'
gebruikt.
maar ik wist niet dat pseudo RNG zo betrouwbaar waren dat het zo lang zou duren om te kraken. Maarja aangezien computers ongeveer elke 3 jaar twee keer zo krachtig worden is dit ook niet echt een garantie voor de toekomst.
Nu, als een ssh-key van 1024-bits vandaag genoeg is, dan is er een van 1025 bits over drie jaar genoeg. Mocht je paranoia zijn, of de techniek neemt ineens een grote sprong, dan neem je 2048-bits keys. Problem solved.
Moederbord? In de CPU is veel handiger. Een moederbord is uiteindelijk een plank die chips verbindt. Het zou natuurlijk ook in de Northbridge kunnen, maar de getallen zijn uiteindelijk in de CPU nodig dus waarom niet meteen daar ? Het is niet alsof er veel transistoren nodig zijn.

Via maakt overigens al CPUs die al zo'n RNG hebben.
Zit al in de updates

The following packages will be upgraded:
libssl-dev libssl0.9.8 openssl
3 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 5804kB of archives.
After unpacking 0B of additional disk space will be used.
Do you want to continue [Y/n]?
Inderdaad, juist binnengehaald via aptitude.
Zelf heb ik ook nieuwe keys aangemaakt, kwestie van op zeker te spelen. Dit kan je doen met behulp van ssh-keygen:
# ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
# ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key
# ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_key

[Reactie gewijzigd door maleadt op 13 mei 2008 17:29]

Even een waarschuwing bij bovenstaande tip:

Als je (zoals ik) niet bijzonder thuis bent in Linux en m.b.v. MALEADt 's methode nieuwe keys gaat aanmaken, geef dan geen passphrase op (met andere woorden, gewoon op 'enter' drukken als je om een passphrase wordt gevraagd).

Geef je wél een passphrase op, dan zal sshd deze niet kennen en daarmee de nieuwe host keys niet kunnen laden. Met als gevolg dat PuTTY e.d. niet meer kunnen verbinden. :)

[Reactie gewijzigd door TommyCP op 13 mei 2008 21:06]

Zit al in de updates
Die updates vernieuwen zwakke keys niet. Dus alleen updates installeren is (nog) niet voldoende.
Bij het upgraden van openssl van Kubuntu kreeg ik het verzoek de users in te lichten dat de keys veranderd zijn. Als ik het goed heb begrepen, heeft de upgrade gelijk de keys veranderd.
Dat kan de update automatisch doen ja, zie:

http://www.ubuntu.com/usn/usn-612-2
OpenSSH host keys can be automatically regenerated when the OpenSSH security update is applied. The update will prompt for confirmation before taking this step.
Hmm, daar heb ik in Debian niks van gezien.
Waarom zou men niet de rng van de kernel gebruiken?

Ik denk dat dit vooral onopgemerkt is gebleven omdat het een aanpassing van Debian is. Onderzoekers richten zich denk ik eerder op vanilla versies van zulke paketten. Extra reden voor distros om voorzichtig met eigen patches te zijn :)

Iig mooi dat er direct een update in de repo zit.

[Reactie gewijzigd door JanDM op 13 mei 2008 17:58]

Ik weet niet of deze random genoeg zijn. Bij het ontwikkelen van device drivers, kwam ik m.b.t. interrupts wel eens de opmerking tegen dat je op moet passen dat je de random number generator niet (nadelig) beinvloed.

Hoe of wat weet ik uit mijn hoofd niet meer, maar bij zoiets cruciaals als SSL gok ik dat je geen risico's neemt en invloed van buitenaf minimaliseert.
Zo krijgt ranDOM number wel een heel aparte bjiklank.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True