RSA ontkent probleem met algoritme
Volgens RSA zit er geen lek in het RSA-algoritme, zoals verschillende onderzoekers eerder deze week aankondigden. De onderzoekers, waaronder de Nederlandse wiskundige Arjen Lenstra, onderzochten 7 miljoen gegenereerde sleutels en ontdekten dat er 27.000 niet willekeurig waren gegenereerd. In totaal waren er zo'n 13.000 sleutels die geen beveiliging bieden en door aanvallers te achterhalen zijn.
"Onze analyse bevestigt dat de data niet wijst op een lek in het algoritme, maar wijst op het belang van een juiste implementatie, met name wat betreft het groeiend aantal ingebedde apparaten die tegenwoordig met het internet verbonden zijn", aldus RSA in een verklaring tegenover Network World.
Robuust
Volgens Ari Juels van RSA is het onderzoek nuttig, maar hij is het niet eens met de onderliggende toon dat er een probleem met het RSA-algoritme is. Het onderzoek mag dan hebben ontdekt dat het RSA-algoritme "minder robuust dan een ander protocol is", maar "het is duidelijk geen probleem in het RSA-algoritme. Het is de manier waarop de sleutels zijn gegenereerd."
RSA krijgt bijval van DNS-onderzoeker Dan Kaminsky. Die prijst de onderzoekers voor het verzamelen van alle data, maar kan zich ook niet in de conclusie vinden. "Belangrijker, correlatie is geen oorzakelijk verband. Dat we een klein aantal slechte sleutels zien op hetzelfde moment dat we RSA zien, betekent nog niet dat de laatste de eerste heeft veroorzaakt."
Het zou interessant zijn als van de "foute" keys bekend kon worden welke implementatie ze ge-genereerd heeft. Dan kan die gerepareerd worden en mensen die van diezelfde implementatie(s) keys hebben, kunnen ze preventief vernieuwen. Ik hoop eigenlijk dat de schrijvers van de paper hier nu achteraan aan het gaan zijn.
Wat ze wel hebben aangetoond is dat het implementeren van dat algoritme niet zomaar aan elke programmeur overgelaten kan worden.
Als je de priemgetallen écht random kiest, dan is de kans dat twee mensen in de wereld dezelfde getallen kiezen miniem. Laat staan dat er zoveel duizenden keren dezelfde getallen worden gekozen.
MV
MV
Verkeerde analogie.
Als je een schrikbarend slechte manier kiest om sleutels te maken, kan dat eigenlijk altijd gevonden worden.
In dit geval is een behoorlijk aantal slechte sleutels gevonden.
Als je weet welke apparaten onder welke omstandigheden zo'n sleutel genereren, kun je voor de bewuste apparaten gewoon op zoek gaan naar de sleutel. Ik verwacht dat er tzt naar voren komt welke apparaten op welke manier hun priemgetallen genereren.
En dat je programma's kunt schrijven die voor die apparaten expliciet op zoek gaan (binnen de veel kleine zoekruimte die het gevolg is van een slechte randomgenerator ) naar die priem factor.
Nu is feitelijk via de omweg van het vergelijken van veel publieke sleutels het bestaan van zwakke sleutelgeneratoren gevonden.
Als die potentiele dief weet dat van jouw automerk maar 10 verschillende sleutels zijn, kan hij met een bosje van tien zo wegrijden.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
