RSA: encryptie-algoritme is veilig
Het rsa-algoritme is veilig, stelt de technisch directeur van RSA, Bret Hartman. Uit onderzoek bleek dat twee op de duizend rsa-keys niet veilig zijn, maar dat ligt niet aan het algoritme zelf, benadrukt Hartman: het gaat fout bij de implementatie.
Dat zei chief technology officer Hartman van RSA tegen Tweakers.net op de RSA Conference die deze week in San Francisco wordt gehouden. RSA is het bedrijf dat onder meer het bekende rsa-algoritme ontwikkelde, dat veel wordt gebruikt om communicatie te versleutelen. Twee weken geleden werd onderzoek gepresenteerd waaruit bleek dat twee op de duizend rsa-keys geen enkele beveiliging bieden. De onderzoekers namen 7,1 miljoen rsa-keys onder de loep om tot die conclusie te komen.
De keys waren onveilig omdat ze een of meer priemfactoren delen. Rsa-sleutels leunen op priemgetallen en bestaan uit een publieke- en een privésleutel. "Het algoritme waarmee die sleutels worden gegenereerd, is veelvuldig onderzocht, en er zijn nooit kwetsbaarheden in gevonden", aldus Hartman. Onveilige sleutels zijn volgens hem het gevolg van een incorrecte implementatie; het algoritme is open, dus iedereen kan software ontwikkelen waarmee sleutels worden aangemaakt.
Het probleem met de onveilige sleutels is dat ze niet willekeurig genoeg zijn. "Dat kan ook aan het onderliggende besturingssysteem liggen", aldus Hartman, als de random number generator van het besturingssysteem minder willekeurig is dan gedacht.
Dat het genereren van single secret-sleutels volgens de onderzoekers veiliger is dan multi-secret-sleutels, is volgens Hartman appels en peren vergelijken. "Een single-secret-sleutel kan totaal willekeurig zijn", legt Hartman uit. "Multi-secret-sleutels zijn aan elkaar gerelateerd en kunnen dus niet totaal willekeurig zijn."
In theorie is single secret-cryptografie dus veiliger, want unieker, maar voor sommige doeleinden zijn dergelijke sleutels niet geschikt: het idee erachter is dat iedereen die over een bepaalde sleutel beschikt, de communicatie kan ontcijferen. Daarvoor moet die sleutel dus echter wel gedeeld worden, wat niet altijd praktisch is. Bij multi-secret-cryptografie zijn er twee sleutels die op elkaar 'passen', een publieke- en een privésleutel. Om de berichten te versleutelen is enkel de publieke sleutel nodig; om te ontcijferen is de privésleutel nodig. Dit principe wordt bijvoorbeeld gebruikt in ssl en tls.
Volgens Hartman moeten bedrijven en organisaties die public key cryptography gebruiken, zich eerder druk maken om de veilige opslag van sleutels. "Problemen met cryptografie hebben vaak vooral te maken met de manier waarop met sleutels wordt omgegaan en niet met het algoritme zelf", zegt hij. Privésleutels worden dan bijvoorbeeld gestolen, zodat de versleuteling kan worden gekraakt, zonder dat er iets mis is met het algoritme zelf.
Dat wil niet zeggen dat er geen gevaren zijn voor het rsa-algoritme. "Op de lange termijn kan bijvoorbeeld quantumcomputing een gevaar vormen", zegt Hartman. Computers zouden dan zo krachtig kunnen worden dat ze de versleuteling kunnen doorbreken. Het is dus belangrijk om ook nu al een minimum-sleutellengte te hanteren; rsa-sleutels van 512bits kunnen nu al worden gekraakt.
Reacties (52)
Sleutels van 512 bits kunnen gekraakt worden? Bij AES is het bij 128 bits al heel erg lastig! Hoe kan dit?
Zie nieuws: Nederlandse wiskundige: 2 op 1000 rsa-keys zijn onveilig in gerelateerde content. Die link staat overigens ook gewoon in de newspost 
[Reactie gewijzigd door ravenger op dinsdag 28 februari 2012 22:45]
AES is een symmetric-key algoritme, waarbij momenteel 128-256 bits als veilig wordt beschouwd.
RSA is een asymmetric-key algoritme, waar men al tot 700 en iets bits kan kraken. 1024 bits is hier het minimum tegenwoordig.
De reden hiervoor is gewoon hoe het wiskundig in elkaar zit en dat is behoorlijk complex.
De reden waarom het hier mis gaat is omdat RSA enkel veiligheid garandeert onder bepaalde voorwaarden en deze voorwaarden worden in vele implementaties geschonden.
RSA is een asymmetric-key algoritme, waar men al tot 700 en iets bits kan kraken. 1024 bits is hier het minimum tegenwoordig.
De reden hiervoor is gewoon hoe het wiskundig in elkaar zit en dat is behoorlijk complex.
De reden waarom het hier mis gaat is omdat RSA enkel veiligheid garandeert onder bepaalde voorwaarden en deze voorwaarden worden in vele implementaties geschonden.
http://en.wikipedia.org/wiki/RSA_Factoring_Challenge
663 is al gelukt.
696 is volgens deze tabel nog niet gelukt.
Maar aangezien het vaak met machten van 2 aantal bits gaat is 1024 inderdaad het minimum.
663 is al gelukt.
696 is volgens deze tabel nog niet gelukt.
Maar aangezien het vaak met machten van 2 aantal bits gaat is 1024 inderdaad het minimum.
De reden dat bij RSA meer bits nodig zijn voor een veilige sleutel is dat de beveiliging gebaseerd is op factorisatie van een groot getal in zijn priemfactoren. Hiervoor zijn redelijk slimme algorithmes bedacht, maar de "moeite" (complexiteit) van de oplossing neemt nog altijd exponentieel toe tov de grootte van het getal.
Het voordeel van RSA is dat deze complexiteit geborgd is door equivalentie aan een grote klasse van wiskundige problemen, die na honderden jaren onderzoek logarithmisch complex (b)lijken te zijn (P != NP).
.
AES is gebaseerd op het "goed door elkaar husselen" van gegevens op basis van 1 geheime sleutel. Vooralsnog zijn hier geen betere aanvalsmethoden voor gevonden dan "alle mogelijkheden uitproberen". Er is echter geen wiskundige basis waarom dit in de toekomst niet zou gaan lukken. Eerder zijn al een aantal veilig geachte, optisch gelijksoortige algorithmes gesneuveld.
.
Voor distibutie van moeder-sleutels is RSA daarom momenteel de beste keus. Met RSA kunnen dan de geheime sleutels van meer praktische algorithmes als AES verspreid worden. Mocht er iets gekraakt worden, dan zijn die sleutels ook snel te vervangen.
Het voordeel van RSA is dat deze complexiteit geborgd is door equivalentie aan een grote klasse van wiskundige problemen, die na honderden jaren onderzoek logarithmisch complex (b)lijken te zijn (P != NP).
.
AES is gebaseerd op het "goed door elkaar husselen" van gegevens op basis van 1 geheime sleutel. Vooralsnog zijn hier geen betere aanvalsmethoden voor gevonden dan "alle mogelijkheden uitproberen". Er is echter geen wiskundige basis waarom dit in de toekomst niet zou gaan lukken. Eerder zijn al een aantal veilig geachte, optisch gelijksoortige algorithmes gesneuveld.
.
Voor distibutie van moeder-sleutels is RSA daarom momenteel de beste keus. Met RSA kunnen dan de geheime sleutels van meer praktische algorithmes als AES verspreid worden. Mocht er iets gekraakt worden, dan zijn die sleutels ook snel te vervangen.
Dit heeft te maken met het feit dat RSA heel anders werkt dan AES. De hoeveelheid tijd die nodig is om iets te berekenen (zoals het kraken van een sleutel) hangt van twee dingen af: de invoergrootte van het probleem (in dit geval het aantal bits) en de structuur van het probleem.
RSA is assymmetrisch en dat betekent dat je een openbare public key en een geheime private key hebt, die onderling aan elkaar gerelateerd zijn. Grof gezegd (en niet helemaal exact) bestaat de private key uit twee priemgetallen en de public key uit deze twee getallen met elkaar vermenigvuldigd. Het kraken van RSA gaat erom dat je de private key weet af te leiden uit de public key. Nu weten we niet hoe moeilijk het exact is om een getal in zijn priemfactoren te ontleden, maar er wordt wel vooruitgang geboekt. Vanuit de complexiteitstheorie (die de moeilijkheid van problemen bestudeert) hebben we ook geen garanties dat priemfactorisatie inderdaad moeilijk is en het is ook niet waarschijnlijk dat die er komen. Mede door deze onzekerheid en het feit dat er nog steeds voortuigang wordt geboekt in onderzoek naar priemgetallen, is het verstandig om grotere sleutels te gebruiken.
AES werkt met block cypher achtige technieken, waarbij je sleutel vooral een manier beschrijft waarop de content gehusseld en volgens vaste patronen vervangen wordt. Hier komen verder geen priemgetallen aan te pas. Daarbij is er maar één sleutel die altijd geheim gehouden worden (tegenover de public key van RSA). Het kraken van AES komt dus neer op achterhalen welke sleutel gebruikt is, gegeven onversleutelde content en de bijbehorende versleutelde content. Dit is eigenlijk dus een hele andere tak van sport.
RSA is assymmetrisch en dat betekent dat je een openbare public key en een geheime private key hebt, die onderling aan elkaar gerelateerd zijn. Grof gezegd (en niet helemaal exact) bestaat de private key uit twee priemgetallen en de public key uit deze twee getallen met elkaar vermenigvuldigd. Het kraken van RSA gaat erom dat je de private key weet af te leiden uit de public key. Nu weten we niet hoe moeilijk het exact is om een getal in zijn priemfactoren te ontleden, maar er wordt wel vooruitgang geboekt. Vanuit de complexiteitstheorie (die de moeilijkheid van problemen bestudeert) hebben we ook geen garanties dat priemfactorisatie inderdaad moeilijk is en het is ook niet waarschijnlijk dat die er komen. Mede door deze onzekerheid en het feit dat er nog steeds voortuigang wordt geboekt in onderzoek naar priemgetallen, is het verstandig om grotere sleutels te gebruiken.
AES werkt met block cypher achtige technieken, waarbij je sleutel vooral een manier beschrijft waarop de content gehusseld en volgens vaste patronen vervangen wordt. Hier komen verder geen priemgetallen aan te pas. Daarbij is er maar één sleutel die altijd geheim gehouden worden (tegenover de public key van RSA). Het kraken van AES komt dus neer op achterhalen welke sleutel gebruikt is, gegeven onversleutelde content en de bijbehorende versleutelde content. Dit is eigenlijk dus een hele andere tak van sport.
RSA is dus mogelijk simpel te kraken.
Alleen het genie dat de priemfactorisatie eenvoudig laat blijken heeft zich nog niet gemeld.
(mijn laatste zin lijkt zichzelf tegen te spreken; een genie nodig om iets eenvoudig te laten zijn
)
Alleen het genie dat de priemfactorisatie eenvoudig laat blijken heeft zich nog niet gemeld.
(mijn laatste zin lijkt zichzelf tegen te spreken; een genie nodig om iets eenvoudig te laten zijn
)Dat spreekt zich helemaal niet tegen. Een wiskundige/natuurkundige vind iets uit als eerste van alle mensen, dat heeft echter enkel zin als daarna veel meer mensen (in dat vakgebied) het kunnen gebruiken. De natuurkunde wetten van newton worden al op de middelbare school behandeld en zijn calculus aan het begin van een technische studie. Neemt niet weg dat Newton nog altijd een genie is. Een stelling gebruiken en een stelling bewijzen verschilt altijd wel een paar tredes kwa moeilijkheid.
AES is ook mogelijk simpel te kraken.
Er moet alleen wel iemand slim genoeg zijn om de fout te vinden.
Er moet alleen wel iemand slim genoeg zijn om de fout te vinden.
Ah, ongeveer wat ik wilde zeggen...
Ik had je reactie echt nog niet gezien. Grappig.
Ook Crypto gehad tijdens de studie?
Ik had je reactie echt nog niet gezien. Grappig.
Ook Crypto gehad tijdens de studie?
[Reactie gewijzigd door Geekomatic op woensdag 29 februari 2012 21:46]
Ik denk inderdaad dat deze sleutels niet meteen zullen gekraakt worden.
Als ik het goed lees is het probleem vooral dat onveilig omgegaan wordt met het opslaan van de private key.
De public key is voor iedereen beschikbar om te encrypteren, voor het decrypteren heb je echter de private key nodig, als deze op een onveilig plaats opgeslagen wordt en gestolen wordt, is je encryptie niets meer waard.
Als ik het goed lees is het probleem vooral dat onveilig omgegaan wordt met het opslaan van de private key.
De public key is voor iedereen beschikbar om te encrypteren, voor het decrypteren heb je echter de private key nodig, als deze op een onveilig plaats opgeslagen wordt en gestolen wordt, is je encryptie niets meer waard.
op http://www.keylength.com/en/ vindt je de meeste recente aanbevelingen van o.a.het NIST, ECRYPT en BSI.
Voor RSA wordt rond de 2048bits keys aanbevolen mocht je enige mate van serieuze security willen (tot ca 2030).
Voor RSA wordt rond de 2048bits keys aanbevolen mocht je enige mate van serieuze security willen (tot ca 2030).
Encryptie ≠ authenticatie. Het verhaaltje van XKCD is dus irrelevant hier.
Het illustreert heel aardig wat een key van N bits in houden kan.
Dat ging over debian linux.
De 2 op de 1000 keys die slecht zijn, zijn slecht omdat er geen goede random priemgetallen gekozen zijn.
Over het algemeen kies je random zaken niet 
Terzijde, dit artikel heeft wel een beetje een hoog "Wij van WC-eend"-gehalte. Zijn er ook andere onderzoekers die dit kunnen bevestigen?
Terzijde, dit artikel heeft wel een beetje een hoog "Wij van WC-eend"-gehalte. Zijn er ook andere onderzoekers die dit kunnen bevestigen?
Inderdaad! :-)
De zen-kunst van randomiseren is te keizen zonder enige beperking of vooringenomenheid.
Dat is lastiger dan dan het wellicht op het eerste gezicht lijkt.
Test: Probeer eens een *echt* willekeurig getal tussen de 0 en de 1000 te kiezen...
Onze hersenen werken dit tegen.
Computers zijn al helemaal vooringenomen met allerlei harde bits in hun geheugen.
De zen-kunst van randomiseren is te keizen zonder enige beperking of vooringenomenheid.
Dat is lastiger dan dan het wellicht op het eerste gezicht lijkt.
Test: Probeer eens een *echt* willekeurig getal tussen de 0 en de 1000 te kiezen...
Onze hersenen werken dit tegen.
Computers zijn al helemaal vooringenomen met allerlei harde bits in hun geheugen.
[Reactie gewijzigd door Geekomatic op woensdag 29 februari 2012 21:53]
Waar ging dat dan precies over? Het is mij namelijk ontgaan 
Je hoeft het überhaupt niet te posten. Ten eerste omdat het een enorme cliché-opmerking is die op t.net na de miljoenste keer echt niet weer opnieuw gemaakt hoeft te worden, en ten tweede omdat het hier sowieso niet van toepassing is. Het is namelijk niet gewoon maar een mening over een eigen product, Bret Hartman heeft helemaal gelijk. Het RSA algoritme heeft zich keer op keer bewezen, en het nieuws van onlangs betekent niet dat er zwakheden zijn gevonden in het algoritme. Waar het fout gaat is dat er verkeerde keys worden gegenereerd. Het enige dat Hartman doet is dat feit nog even benadrukken.
[Reactie gewijzigd door .oisyn op woensdag 29 februari 2012 03:06]
Al is het natuurlijk wel zo dat zelfs als deze technisch directeur een zwakheid zou weten, hij die waarschijnlijk niet naar voren zou brengen... Dat zou hem het bedrijf kosten.
Nou, het lijkt me dat het hem het bedrijf kost wanneer hij dat niet naar buiten brengt. Uit komt het uiteindelijk toch wel aangezien iedereen exact in kan zien hoe het algoritme werkt.
In het laatste stukje lees ik:
Een bit heeft nu 2 mogelijkheden; een 1 of een 0. Bij quantumcomputing was dit toch juist veel meer en zouden er dus ook meteen complexere keys gegenereerd kunnen worden?
ik zou het wel mis hebben hoor, maar zal quantumcomputing ook geen invloed hebben op het genereren van de keys?Op de lange termijn kan bijvoorbeeld quantumcomputing een gevaar vormen
Een bit heeft nu 2 mogelijkheden; een 1 of een 0. Bij quantumcomputing was dit toch juist veel meer en zouden er dus ook meteen complexere keys gegenereerd kunnen worden?
De enige reden om niet direct al veel langere sleutels te gebruiken is performance.
Tegen de tijd dat computers zo krachtig zijn dat ze de huidige sleutels kunnen ontcijferen, gebruiken we ook veel grotere sleutel, immers is het performance probleem tegen die tijd veel kleiner.
Het probleem zit er dan ook vooral in de gedacht dat je encrypted data slechts beveiligt is voor de komende x jaar. Praktisch elke encryptie standaard levert een verwachte levensduur aan van de standaard, hoewel dat natuurlijk erg natte vinger werk is.
Tegen de tijd dat computers zo krachtig zijn dat ze de huidige sleutels kunnen ontcijferen, gebruiken we ook veel grotere sleutel, immers is het performance probleem tegen die tijd veel kleiner.
Het probleem zit er dan ook vooral in de gedacht dat je encrypted data slechts beveiligt is voor de komende x jaar. Praktisch elke encryptie standaard levert een verwachte levensduur aan van de standaard, hoewel dat natuurlijk erg natte vinger werk is.
Je hebt gelijk. Quantumcomputers maken nieuwe vormen van encryptie mogelijk: http://en.wikipedia.org/wiki/Quantum_cryptography.
Het is echter niet zo, zoals jij suggereert, dat je simpelweg de oude algoritmen kunt blijven gebruiken met sleutels in superpositie.
Het is echter niet zo, zoals jij suggereert, dat je simpelweg de oude algoritmen kunt blijven gebruiken met sleutels in superpositie.
[Reactie gewijzigd door z.jeroen op dinsdag 28 februari 2012 23:30]
Het duurt nog heel lang voordat QKI(?) het huidige PKI op internet gaat vervangen omdat koperlijntjes niet erg geschikt zijn en er alternatieven zijn die wel bestendig zijn tegen QC kraken. Het huidige PKI zal nog wel een aantal iteraties ondergaan om ook de betrouwbaarheid te verhogen van certificaatuitgevers. Misschien door meerdere partijen laten ondertekenen etc.
Er zijn nogal wat verschillende definities van wat een quantumcomputer is.
De oorspronkelijke definitie was er eentje die megasnel zou zijn en dus RSA eventjes zou kraken, overigens daarbij ook enorm veel RAM gebruikend, in polynomiale tijd.
Recentelijk heeft IBM de kreet gekaapt en is een quantumcomputer gewoon een computer die werkt op licht. Veel sneller dus dan electronica die we nu hebben, waarbij electronen op zeg 1/3 van de lichtsnelheid zich voortbewegen, maar niet in de buurt bij de snelheid van de quantumcomputer zoals begin jaren 90 beschreven.
Dus die ibm machine gaat fiks wat bits RSA niet snel kraken met de huidige ECM
(google op ecm.exe downloadbaar bij INRIA te Frankrijk) methode. Die vreet overigens stevig RAM en is takketraag.
De oorspronkelijke quantumcomputer gedachte was een analoge computer. Nu is het zeer de vraag dus of een analoge computer wel is wat je wilt; bovendien hebben quantums ook nog een erg korte levensduur, dus de computer bestaat erg kort.
Veel geld uitgeven voor een computer die een fractie van een seconde bestaat?
De oorspronkelijke definitie was er eentje die megasnel zou zijn en dus RSA eventjes zou kraken, overigens daarbij ook enorm veel RAM gebruikend, in polynomiale tijd.
Recentelijk heeft IBM de kreet gekaapt en is een quantumcomputer gewoon een computer die werkt op licht. Veel sneller dus dan electronica die we nu hebben, waarbij electronen op zeg 1/3 van de lichtsnelheid zich voortbewegen, maar niet in de buurt bij de snelheid van de quantumcomputer zoals begin jaren 90 beschreven.
Dus die ibm machine gaat fiks wat bits RSA niet snel kraken met de huidige ECM
(google op ecm.exe downloadbaar bij INRIA te Frankrijk) methode. Die vreet overigens stevig RAM en is takketraag.
De oorspronkelijke quantumcomputer gedachte was een analoge computer. Nu is het zeer de vraag dus of een analoge computer wel is wat je wilt; bovendien hebben quantums ook nog een erg korte levensduur, dus de computer bestaat erg kort.
Veel geld uitgeven voor een computer die een fractie van een seconde bestaat?
Volgens mij valt dat wel mee. Kijk eens hier: http://en.wikipedia.org/wiki/Quantum_computerEr zijn nogal wat verschillende definities van wat een quantumcomputer is.
Kom op. Dit is toch geen definitie?De oorspronkelijke definitie was er eentje die megasnel zou zijn en dus RSA eventjes zou kraken, overigens daarbij ook enorm veel RAM gebruikend, in polynomiale tijd.
Het is niet gewoon een computer die werkt op licht. Een quantumcomputer is fundamenteel anders omdat het slim gebruik maakt van entanglement en superpositie. Dat kan met licht, maar hoeft niet. Het is ook nog eens zo dat niet alle problemen sneller worden opgelost door een quantum computer.Recentelijk heeft IBM de kreet gekaapt en is een quantumcomputer gewoon een computer die werkt op licht. Veel sneller dus dan electronica die we nu hebben, waarbij electronen op zeg 1/3 van de lichtsnelheid zich voortbewegen, maar niet in de buurt bij de snelheid van de quantumcomputer zoals begin jaren 90 beschreven.
[Reactie gewijzigd door z.jeroen op vrijdag 2 maart 2012 10:03]
Ja, je hebt het mis. Quantum computers werken fundamenteel anders dan de huidige computers.
Encryptie is voornamelijk gebaseerd op het gegeven dat het wiskundig onmogelijk is om te bepalen wat de sleutel zou moeten zijn wanneer je die sleutel niet hebt en dat je eigenlijk alle mogelijke sleutels zou moeten proberen om te kijken welke past. Door genoeg bits te nemen betekend dat dat zelfs een supercomputer tot het einden der tijden bezig is om alle sleutels te proberen. (bedenk daarbij dat elke bit die toegevoegd wordt er voor zorgt dat het aantal mogelijke sleutels verdubbeld en het zoeken dus 2x zo lang duurt. 8 bits toevoegen maakt het al 256x zo lang)
Theoretisch gezien kan een quantum computer alle mogelijkheden tegelijk proberen waardoor er eigenlijk in 1 stap een antwoord te bepalen is. Elke huidige vorm van encryptie wordt op dat moment waardeloos.
Encryptie is voornamelijk gebaseerd op het gegeven dat het wiskundig onmogelijk is om te bepalen wat de sleutel zou moeten zijn wanneer je die sleutel niet hebt en dat je eigenlijk alle mogelijke sleutels zou moeten proberen om te kijken welke past. Door genoeg bits te nemen betekend dat dat zelfs een supercomputer tot het einden der tijden bezig is om alle sleutels te proberen. (bedenk daarbij dat elke bit die toegevoegd wordt er voor zorgt dat het aantal mogelijke sleutels verdubbeld en het zoeken dus 2x zo lang duurt. 8 bits toevoegen maakt het al 256x zo lang)
Theoretisch gezien kan een quantum computer alle mogelijkheden tegelijk proberen waardoor er eigenlijk in 1 stap een antwoord te bepalen is. Elke huidige vorm van encryptie wordt op dat moment waardeloos.
Theoretisch gezien kan een quantum computer alle mogelijkheden tegelijk proberen waardoor er eigenlijk in 1 stap een antwoord te bepalen is. Elke huidige vorm van encryptie wordt op dat moment waardeloos.
zeker interessant maar dit stuk vat ik niet helemaal.
Heb je mischien ook iets van een bron het is namenlijk wel interessant.
zeker interessant maar dit stuk vat ik niet helemaal.
Heb je mischien ook iets van een bron het is namenlijk wel interessant.
Het feit dat de priemfactoren zo random mogelijk moeten zijn, is gewoon het "core-concept" van RSA. Bij elke public key, is er immers maar 1 mogelijke private key mogelijk.
Maw: als je zelf keypairs genereert, zou je de public key van deze pair kunnen beginnen vergelijken met public keys van gekende instanties. Als je dan een match hebt, weet je dat je ook bijhorende private key hebt gegenereerd. Vandaar dat het random-aspect (of eigenlijk pseudo-random) zo belangrijk is: om zulke "toevalstreffers" tegen te gaan.
En dan heb ik nog niet over het feit dat bij RSA bepaalde informatie zowel in de public key, als in de private key beschikbaar is, nl: de n-factor, die zowel voor de encryptie, als voor de decryptie nodig is. Kortom eigenlijk heb je al een stukje van de private key in handen, als je de public key hebt :-) Maar zolang er geen snel algoritme bestaat dat een getal van enkele honderden cijfers snel kan ontbinden in priemfactoren, is dit geen probleem.
Maw: als je zelf keypairs genereert, zou je de public key van deze pair kunnen beginnen vergelijken met public keys van gekende instanties. Als je dan een match hebt, weet je dat je ook bijhorende private key hebt gegenereerd. Vandaar dat het random-aspect (of eigenlijk pseudo-random) zo belangrijk is: om zulke "toevalstreffers" tegen te gaan.
En dan heb ik nog niet over het feit dat bij RSA bepaalde informatie zowel in de public key, als in de private key beschikbaar is, nl: de n-factor, die zowel voor de encryptie, als voor de decryptie nodig is. Kortom eigenlijk heb je al een stukje van de private key in handen, als je de public key hebt :-) Maar zolang er geen snel algoritme bestaat dat een getal van enkele honderden cijfers snel kan ontbinden in priemfactoren, is dit geen probleem.
"kortom, eigenlijk heb je al een stukje van de private key in handen"- zo kan je alles wel 'bekend deel' van de private key noemen. Natuurlijk, je hebt n nodig, maar d is het eigenlijke private-gedeelte.
Klopt wat je zegt, maar aangezien n wel degelijk gebruik wordt voor de encryptie, is het wel degelijk een onderdeel van de private key, en niet zomaar wat "bijkomstige informatie". Als je 'n' immers kan ontbinden in zijn priemfactoren kan je 'd' immers wiskundig berekenen.
[Reactie gewijzigd door sithlord2 op woensdag 29 februari 2012 09:46]
Uit het artikel:) de enige die jouw privésleutel weet. Dit is ook het principe achter certificaten, al wordt dan typisch niet het hele bericht (het certificaat) vercijferd, maar slechts een message digest ervan. Een client kan de afzender van een certificaat verifiëren door de geëncrypte hash te decrypten met de publieke sleutel van de afzender, en die te controleren met de hash die je zelf hebt uitgerekend.
Dat is een beetje kort door de bocht. Voor typische encryptie zal het zo gebruikt worden, maar het is absoluut niet zo dat het bericht alleen te encrypten is met de publieke sleutel en te decrypten met de privésleutel. Wiskundig gezien transformeer je de data met de sleutels, en zijn de twee sleutels gewoon elkaars inverse. Je kunt dus ook encrypten met je privésleutel, en weer decrypten met de publieke sleutel. Natuurlijk niet heel handig om te voorkomen dat iemand meeleest, want iedereen kan het bericht ontcijferen met jouw publieke sleutel. Maar dit kan wél gebruikt worden om de afzender te verifiëren - alleen jij kan het bericht vercijferd hebben als het met jouw publieke sleutel te ontcijferen is, want jij bent (als het goed isOm de berichten te versleutelen is enkel de publieke sleutel nodig; om te ontcijferen is de privésleutel nodig
) de enige die jouw privésleutel weet. Dit is ook het principe achter certificaten, al wordt dan typisch niet het hele bericht (het certificaat) vercijferd, maar slechts een message digest ervan. Een client kan de afzender van een certificaat verifiëren door de geëncrypte hash te decrypten met de publieke sleutel van de afzender, en die te controleren met de hash die je zelf hebt uitgerekend.[Reactie gewijzigd door .oisyn op woensdag 29 februari 2012 03:16]
SImpel gezegd: het ligt eraan wat je wilt:
- Wil je zorgen dat niemand mee kan kijken, encrypt dan met de public key van de ontvanger
- Wil je garanderen dat jij de afzender bent, encrypt dan met je eigen private key
Iets geencrypt met de public key kan alleen gedecrypt worden met de private key, en vice versa.
http://en.wikipedia.org/wiki/Public-key_cryptography
- Wil je zorgen dat niemand mee kan kijken, encrypt dan met de public key van de ontvanger
- Wil je garanderen dat jij de afzender bent, encrypt dan met je eigen private key
Iets geencrypt met de public key kan alleen gedecrypt worden met de private key, en vice versa.
http://en.wikipedia.org/wiki/Public-key_cryptography
Fijn dat je mijn post nog even samenvat, bedankt
Ja dat is leuke theorie allemaal, maar wat als ik het netwerk in handen heb dat alle communicatie tussen de 2 partijen verzorgt? Dan kun je toch alles modificeren zoals
je het zelf wilt?
Sterker nog als iets minder dan 1% van de sleutels al met een GCD dezelfde niet-random priemgetal heeft, dan zou ik me afvragen welke software zo doortrapt is
je het zelf wilt?
Sterker nog als iets minder dan 1% van de sleutels al met een GCD dezelfde niet-random priemgetal heeft, dan zou ik me afvragen welke software zo doortrapt is
Oh ja en voeg eraan toe: "wij van WC-eend die 12 jaar geleden nog vet geld uitkeerden als je de challenges wist te factoriseren, die keren geen geld hier meer voor uit sinds een jaar of 10".
Dus je verdient niets als je de RSA challenges factoriseert.
Wel met AES, maar ja AES is niet zo interessant, want die mag van de NSA alleen maar tot 'secret' gebruikt worden, dus het gros van de desinformatie die wikileaks verspreidt, die mag je nog niet eens encrypten met AES, maar wel met RSA4096
Dus je verdient niets als je de RSA challenges factoriseert.
Wel met AES, maar ja AES is niet zo interessant, want die mag van de NSA alleen maar tot 'secret' gebruikt worden, dus het gros van de desinformatie die wikileaks verspreidt, die mag je nog niet eens encrypten met AES, maar wel met RSA4096
het algoritme is open, dus iedereen kan software ontwikkelen waarmee sleutels worden aangemaakt.
En daarmee is het algoritme dus wel onveilig, want hoe weet iemand of er een veilige versie van het algoritme is geimplementeerd, dat kan dus alleen als er ook strenge regels vastliggen over de implementatie van het algoritme.. Ofwel het algoritme mag dan in theorie wel veilig zijn, maar doordat de implementatie onveilig gedaan kan worden wordt de encryptie dus niet gegarandeerd en daarmee is de RSA encryptie als onveilig te bestempelen.
En daarmee is het algoritme dus wel onveilig, want hoe weet iemand of er een veilige versie van het algoritme is geimplementeerd, dat kan dus alleen als er ook strenge regels vastliggen over de implementatie van het algoritme.. Ofwel het algoritme mag dan in theorie wel veilig zijn, maar doordat de implementatie onveilig gedaan kan worden wordt de encryptie dus niet gegarandeerd en daarmee is de RSA encryptie als onveilig te bestempelen.
Als je die redenering aanhoudt, is elk encryptie algorithme onveilig, met uitzondering van XOR-encryptie, en enkel als je een key gebruikt die lang genoeg is (= even lang als het bericht dat je versleutelt), en slechts éénmalig gebruikt. Dat is het enige encryptie-algoritme tot op heden dat 100% veilig is.
Op dit moment is de consensus "veilig genoeg" mits je volgende voorwaarden in acht neemt:
- De priemgetallen zijn lang genoeg zodat het product van deze twee getallen ongelooflijk veel tijd in beslag neemt om terug te ontbinden.
- De gebruikte priemgetallen zijn niet voorspelbaar.
Zulke afwegingen zijn geldig voor elk encryptie-algorithme.
Op dit moment is de consensus "veilig genoeg" mits je volgende voorwaarden in acht neemt:
- De priemgetallen zijn lang genoeg zodat het product van deze twee getallen ongelooflijk veel tijd in beslag neemt om terug te ontbinden.
- De gebruikte priemgetallen zijn niet voorspelbaar.
Zulke afwegingen zijn geldig voor elk encryptie-algorithme.
[Reactie gewijzigd door sithlord2 op woensdag 29 februari 2012 09:43]
Volgens die beredenering kan zelfs 'XOR-encryptie' onveilig zijn als je de key lekker ergens op een publieke server zet.
Ok, maar bij encryptie gaan we er altijd van uit dat het geheim in de sleutel ligt, en niet in het algoritme. Mijn stelling gaat dus puur over het algoritme.
kortom implementatie is alles en al die publiek beschikbare implementaties zuigen enorm.
Gewoon met een GCD al een bende RSA sleutels kunnen factoriseren is wel heel erg schandalig.
windows bitlocker die AES gebruikt hoef je overigens ook niet te gebruiken, die implementatie zuigt ook.
ik herinner me dat ik een keer de unlock key van bitlocker foutief had ingetypt.
Liet het ding me zien in welk blok digits ik een fout had gemaakt!
De usb stick met de geheime sleutel zat toen niet in de computer
En hoe kan hij dat weten zonder de key op te slaan, of zonder hashing algoritme waarbij de reverse engineering een fluitje van een cent is?
Het kernprobleem is dat je eigenlijk niks goed mag encrypten. Zie www.wassenaar.org
Daarin zul je terugvinden dat eigenlijk alles dat boven de 512 bits public key encrypt,
dat dit zwaar illegaal is.
Er is nu 1 uitzondering gemaakt, slechts en enkel, ter beveiliging van multi-media software.
Gewoon met een GCD al een bende RSA sleutels kunnen factoriseren is wel heel erg schandalig.
windows bitlocker die AES gebruikt hoef je overigens ook niet te gebruiken, die implementatie zuigt ook.
ik herinner me dat ik een keer de unlock key van bitlocker foutief had ingetypt.
Liet het ding me zien in welk blok digits ik een fout had gemaakt!
De usb stick met de geheime sleutel zat toen niet in de computer
En hoe kan hij dat weten zonder de key op te slaan, of zonder hashing algoritme waarbij de reverse engineering een fluitje van een cent is?
Het kernprobleem is dat je eigenlijk niks goed mag encrypten. Zie www.wassenaar.org
Daarin zul je terugvinden dat eigenlijk alles dat boven de 512 bits public key encrypt,
dat dit zwaar illegaal is.
Er is nu 1 uitzondering gemaakt, slechts en enkel, ter beveiliging van multi-media software.
wassenaar agreement heft die beperking op voor de signatories waaronder Nederland en België. Je mag het enkel niet exporteren naar pakweg Iran.
Als die unlock key eigenlijk 20 digits lang is en je moet 5 blokken van 5 intikken omdat elke 5e digits een controle is over de vorige 4 dan kan je prima aangeven welk blok er fout is.
ja die XOR theorie is heel fijn, maar zonder die in combinatie met wat anders te gebruiken gaat XOR natuurlijk ook niet werken
Je zou maar eens een kritieke passages per ongeluk met nullen XORen
Je zou maar eens een kritieke passages per ongeluk met nullen XORen
met XOR bedoel je de one-time pad benadering: veilig onder 2 voorwaarden
- sleutel mag niet hergebruikt worden (ook niet binnen hetzelfde bericht)
- sleutel moet volledig random zijn: geen gebruik van pseudo-random generatoren
Op dit item kan niet meer gereageerd worden.
Populair: Android Tablets Samsung Websites en communities Mobiele telefoons Google Microsoft Sony Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
