OpenSSH introduceert ondersteuning voor veiligere cryptografiemethode

De ontwikkelaars van OpenSSH hebben een nieuwe versie vrijgegeven waarin onder meer ondersteuning voor elliptic curve cryptography is toegevoegd. Die cryptografische methode wordt steeds vaker gebruikt voor het versleutelen van communicatie.

Elliptic curve cryptography is de standaard key exchange-methode nu zowel de OpenSSH-server als -client de methode ondersteunen, zo blijkt uit de changelog van OpenSSH 6.5. De ontwikkelaars van de populaire terminaltool, die door veel sysadmins wordt gebruikt om servers te beheren, hebben gekozen voor het Curve25519-systeem, dat ook door onder meer Tor en Cryptocat wordt gebruikt. Desgewenst kan echter ook voor het Ed25519-systeem worden gekozen.

Ssh, waarvan OpenSSH de bekendste opensource-implementatie is, leunt op de uitwisseling van sleutels om een beveiligde verbinding op te zetten, net zoals bijvoorbeeld https. Daarbij wordt gebruikgemaakt van public key cryptography, waarbij publieke sleutels kunnen worden uitgewisseld over een onbeveiligd kanaal zonder dat de privésleutel op straat komt te liggen. Public key-cryptografie verschilt daarmee van shared key cryptography, waarbij een gedeelde sleutel wordt gebruikt. Elliptic curve-cryptografie is moeilijker te kraken dan klassieke algoritmen zoals rsa.

Verder ondersteunt OpenSSH 6.5 een nieuw formaat voor privésleutels waardoor de sleutels beter beschermd zouden moeten zijn. Daarnaast weigert de OpenSSH-server vanaf nu oudere algoritmes, zoals rsa in combinatie met md5. Tot slot is er een aantal bugs geplet, al lijken daar geen ernstige bugs onder te zijn. Ook is de output naar de logfiles verbeterd.

Reacties (75)

Password-protected private keys in het OpenSSH formaat ("id_rsa") zijn encrypted met een key afgeleid van één MD5 iteratie over het wachtwoord (zie Tom Leek's uitleg).

Het nieuwe bcrypt key formaat is zeker welkom om langer te slapen na een verloren key, maar voor oudere versies kan je ook PBKDF2 gebruiken. Standaard worden dan 2048 iteraties van md5 gebruikt door openssl, zie deze post voor een patch waarmee je een hoger aantal iteraties kunt instellen.

[Reactie gewijzigd door .Peter. op 30 januari 2014 17:43]

Wat background info over die Elliptic Curve Cryptography: http://arstechnica.com/se...iptic-curve-cryptography/

Wat ik me nou wel hardop afvraag, was dit nou niet een cryptografie met een halve achterdeur? http://crypto.stackexchan...ecommended-ecc-parameters

Hier ook een filmpje van Numberphile http://www.youtube.com/watch?v=ulg_AHBOIQU word elliptic curve cryptography uitgelegt. Hier word wel meer ingegaan op de manier de NSA email heeft kunnen kraken.

[Reactie gewijzigd door Rexel op 30 januari 2014 10:26]

Wellicht is het makkelijker voor de meesten om eerst de algemene principes achter public key cryptografie te snappen voordat ze hier in duiken vond zelf deze video dat wel aardig uitleggen: https://www.youtube.com/watch?v=3QnD2c4Xovk

De vermeende (of echte) backdoor waarover je schrijft zit in een elliptic curve random-number generator ( https://en.wikipedia.org/wiki/Dual_EC_DRBG ), niet in elliptic curve cryptografie als zodanig.

Aaah, close but not close enough! Bedankt voor de opheldering

Let ook op hoe uitgebreid groot sommige cryptografische implementaties zijn, terwijl mijn eigen code maar enige tientallen kilobytes is. Groter dan dat hoeft het echt niet te zijn.

Serieuze noot: Het is natuurlijk prima als jij je eigen implementaties schrijft, voor studie of als oefening, maar ALSJEBLIEFT, gebruik ze niet voor productie, en zeker niet voor de gegevens van andere mensen.

Encryptie is HEEL HEEL HEEL erg moeilijk, en je kunt echt heel veel fout doen. Er zijn maar een zeer klein aantal mensen wereldwijd die slim genoeg zijn om encryptiealgorithmen kunnen ontwerpen en implementeren, en dan nog gaat dit altijd met behulp van uitgebreide tests, peer review, etc.

Regel 1 van encryptie: gebruik libraries, en niet je eigen oplossing.

Je hebt een eigen implementatie van cryptografische algoritmes geschreven?
Maar hoe goed is jouw implementatie bestand tegen side-channel attacks, om maar iets te noemen. Het mathematische aspect is niet het enige waarop gelet moet worden om een goede implementatie van een cryptografisch algoritme te schrijven.

In iets wat onoverzichtelijk klein is is het ook niet moeilijk.
Probeer maar eens de code van de ioccc winnaars te checken op slecht gedrag...

Je eigen code? Uit je reacties kan ik anders duidelijk merken dat je nog nooit in je leven een cryptografische implementatie hebt geprogrammeerd want je loopt een boel onzin te verkopen in dit topic. En als ik het verkeerd heb dan zie ik graag een linkje naar wat van je eigen code.

Direct linkje? Of moet ik 5000 topics gaan lopen doorzoeken?

Edit: Geen linkje uren later ... dus we hebben hier te maken met een internet fantast die met wat moeilijke woorden en copypast een niet coherent verhaaltje post dat nergens op trekt.

[Reactie gewijzigd door Kain_niaK op 30 januari 2014 18:51]

De vermeende (of echte) backdoor waarover je schrijft zit in een elliptic curve random-number generator ( https://en.wikipedia.org/wiki/Dual_EC_DRBG ), niet in elliptic curve cryptografie als zodanig.

Bovendien is dat een random number generator en geen pubkey system.

Was de elliptic curve-ondersteuning in Ubuntu en dergelijke dan een onofficiele patch?

Ik kom inderdaad ook al tijden ECDSA support tegen op diverse platforms, volgens mij zit de support er al sinds OpenSSH 6.2 in als ik op het internet kijk. Dus waarom het nu ineens wordt aangekondigd is me niet duidelijk; misschien is het nu de voorkeursmethode voor versleuteling geworden?

Laat je niks wijsmaken door Tweakers, ECC (specifiek ECDSA) zat inderdaad al lang in OpenSSH. Wat nu toegevoegd is, zijn nieuwere algorithmes, namelijk Curve25519 voor key exchange en Ed25519 voor encryptie.

In het verleden waren er export restricties voor sterke crypto. Tegenwoordig is dat niet meer relevant.

ECC is sterker en vooral een heel stuk sneller dan RSA. Ik weet niet of jij wel eens lange RSA keys hebt gebruikt in de praktijk, maar ik denk dat je een keer een 8192 (of 4096) bit key maakt en dan kijkt hoe lang een SSH handshake duurt.

RSA gebruiken voor encryptie ipv puur voor de authenticatie is in mijn ogen niet te doen. Vooral omdat de key lengte je bericht lengte beperkt en dat het *heel* *erg* *traag* is.

Als je een goede primer over ECC leest dan lees je dat het elliptic curve discrete logarithm problem een moeilijker probleem is dan zowel het RSA probleem ("factoriseer N") als het normale discrete logarithm probleem.

Kortom;
Wat jij voorstelt is niet mogelijk en niet veiliger.

De restricties voor crypto zijn nog veel heftiger nu.

Het is zo erg nu dat je zelfs niet in producten de cryptography als gebruiker mag veranderen.

Wassenaar treaty 08 - WA-LIST (13) 1 - Cat 5P2 "Information Security" Note 3:
"The cryptographic functionality cannot easily be changed by the user;"

Note 4:

"
b. The cryptographic functionality is limited to supporting their primary function or set of functions; and
c. When necessary, details of the items are accessible and will be provided, upon request, to the appropriate authority in the exporter’s country in order to ascertain compliance with conditions described in paragraphs a. and b. above.
"

Dus ALS er sprake is van cryptografie, dan heeft Nederland ervoor getekend, net als USA en Rusland en vele andere landen, dat ze dan er ZEKER van zijn dat ze het RECHT hebben om alle data in de hardware en de hardware zelf te inspecteren.

Kortom iets VERBERGEN op welke manier dan ook is onmogelijk tegenwoordig, sinds het Wassenaarverdrag in werking is getreden.

Het staat overigens vol met limitaties t.a.v. cryptografie.

Je kunt de afspaken vinden: http://www.wassenaar.org/controllists/index.html

Verder is er nog een NATIONALE beperking van EZ (Economische Zaken).
Voor exporteren van producten die meer dan 512 bits cryptografie kunnen ontrafelen dien je dus een EXPORTVERGUNNING aan te vragen als je dat BUITEN de Benelux wilt exporteren.

Jawel, we leven in de EU. Het is fijn.

Het belangrijkste algoritme wat DUS in aanmerking komt waartegen speciale belemmeringen zijn opgeworpen, afgezien van de "we want to know it all" wetten, die belemmeringen betreffen specifiek enkel en alleen RSA...

Het uitrekenen van RSA voor een bit of 8k op hedendaagse processoren gaat in millisecondes.

het is een loopje die maar 8192 rond hoeft in geval van 8192 bits

Of nog minder als we de private key gebruiken

Op processoren uit 1970 was dat inderdaad een probleem en ook in de jaren 80 was vermenigvuldigen niet zo snel op de processoren...

Dat is nu dus wel anders hoor!

[Reactie gewijzigd door hardwareaddict op 30 januari 2014 11:54]

Volgens mij heb je niet echt in de gaten dat rsa momenteel nooit voor encryptie van communicatie gebruikt wordt. Maar enkel voor authenticatie. Verdiep je eens in de techinische kant van het onderwerp.

Hier bijvoorbeeld: http://www.youtube.com/watch?v=wXB-V_Keiu8

Niet alleen voor authenticatie, RSA wordt ook gebruikt om de (symmetrische) encryptie sleutel voor communicatie over te dragen bij bijv. SSL verbindingen. Dus het speelt wel een rol in de data encryptie. Maar alleen tijdens het handshake proces.

RSA wordt daarbij gebruikt om de symmetrische (meestal AES) sleutel ge-encrypt over te dragen, anders zou iedereen die de sessie meeluistert de sleutel gewoon kunnen zien.

Goh, ik herinner me nog dat ik voor 't RIVM ooit eens RSA heb zitten implementeren voor het interne netwerk, om data te versleutelen tijdens 't communiceren. Het is alweer bijna 20 jaar geleden dat ik dat gedaan heb

Probeer je je argumenten nou kracht bij te zetten door zogenaamd relevante kennis aan te tonen? Ik hoop dat je beseft dat de moeilijkheid van dergelijke algoritmes zit in het bedenken ervan, en vooral in het bewijs dat ze lastig te kraken zullen zijn (waarbij je natuurlijk wel uitgaat van bepaalde axioma's binnen de bekende wiskunde). RSA is doodsimpel om te implementeren, dat heb ik geloof ik eens voor een opdracht discrete wiskunde van mijn HBO informatica opleiding moeten doen. Je reacties hier geven echter aan dat je verder nogal wat achterliggende kennis mist, zoals aangetoond door de vele posters hier in dit artikel. Dat is niet erg, maar ga nou niet doen alsof je het allemaal wel weet.

In de jaren zeventig heeft NSA aan touwtjes getrokken om de sleutel lengte van DES te beperken tot 56 bits. Dat NSA nu elliptic curve encryption promoot en NIST heeft toegestaan AES met een sleutellengte van 256 bits als standaard te publiceren geeft toch te denken.

..dat wil je in 'the first place' niet over 't internet communiceren en enkel met streng geheime algoritmes encrypten, die niet publiek zijn....

Serieus? Security door obfuscatie of geheimhouding van uw algoritme? Dat lijkt me geen goede aanbeveling.

Wil je wetenschappelijke litaratuur of iets begrijpelijkers?
Zie http://blog.cloudflare.co...liptic-curve-cryptography voor een mooie uitleg.

You can compute how much energy is needed to break a cryptographic algorithm, and compare that with how much water that energy could boil. This is a kind of cryptographic carbon footprint. By this measure, breaking a 228-bit RSA key requires less energy to than it takes to boil a teaspoon of water. Comparatively, breaking a 228-bit elliptic curve key requires enough energy to boil all the water on earth. For this level of security with RSA, you'd need a key with 2,380-bits.

[Reactie gewijzigd door RedPixel op 30 januari 2014 10:40]

Hierbij moet worden opgemerkt dat de benodigde energie berekend wordt met het best bekende algoritme.

Dus als iemand een efficiënter algorithme heeft, kost het hem minder energie om te kraken en neemt de sterkte van de encryptiemethode af. Hier komt dus het voorbehoud terug dat locke960 hierboven noemt:

voor zover wij nu weten, naar de unanieme mening van alle experts op dit gebied

AES kun je omschrijven naar een factorisatieprobleem.

Volkomen quatsch. AES heeft niets te maken met factoriseren.

Hij is lekker bezig in dit topic ... ergens schrijft hij ook nog dat zijn "eigen code" maar een 10tal kb groot is. Ik geloof niet echt dat hardwareaddict überhaupt kan programmeren, laat staan cryptografische programma's. Behalve misschien ROT26, dat zou misschien nog net gaan.

Behalve misschien ROT26, dat zou misschien nog net gaan.

Nog net, ja
En daarna claimen dat het een geavanceerde vorm van hide in plain sight is

Zijn computer is echter wel goed bezig. Heeft zomaar priem getal 69 maal 2 tot de 22649939 macht - 1 gevonden.
http://primes.utm.edu/bios/page.php?id=4088

Join de discussie op mijn profiel pagina .... ergens geen verstand van hebben ... daar heeft iedereen last van ... maar leren is zo gemakkelijk in deze tijd want het internet is het mooiste geschenk ooit, in dat opzicht.

Geldt dat niet voor de meeste mensen hier? Hoeveel reageerders hebben hier eigenlijk wiskunde gestudeerd en zijn vervolgens door gegaan op een cryptografische relevant vakgebied?

Ik heb zelf nooit te maken gehad met elliptische krommen om maar eens een voorbeeldje te noemen. De hele discussie moet ik dan ook maar aannemen wat mensen allemaal beweren.

Ik snap ook niet alles, maar de basis van cryptografie valt te begrijpen door iedereen die slim genoeg is om lagere wiskunde te begrijpen. Deze video kan ik bijvoorbeeld prima begrijpen --> http://www.youtube.com/watch?v=ko62sibi668
ook al moet ik hem regelmatig pauseren om mijn tijd te nemen op een blad papier voor me. En deze video gaat over de basis van veilige communicatie op het internet. Hoe verstuurd Alice een boodschap naar Bob, zonder dat Eve kan meeluisteren. Maar Alice en Bob hebben elkaar nog nooit ontmoet en moeten dus eerste via een publieke sleutel een geheime sleutel afspreken ... zonder dat Eve die te pakken krijgt. Deze video legt het uit en wanneer je het snapt dan denk je: Hey, da's best ingenious.

Dus ook al ben ik geen wiskundige ... en ken ik alle formules niet uit mijn hoofd, ik ben slim genoeg om complexe algoritmes onder te verdelen in de eenvoudige bouwstenen ervan.

En dan kan ik prima weten dat wat hardware addict allemaal zegt onzin is.

Elliptische krommen zijn weer een stuk ingewikkelder ... maar je kunt het vereenvoudigen en dan begrijp ik het een klein beetje beter.

Ja dat soort filmpjes begrijp ik ook wel. Bij cryptgrafie gaat het er ook om dat de output data geen clues achter laat over de input data. Als het ware moeten de output bytes er volkomen random uit zien. Ze doen bij al die cryptografische algoritmes een hoop operaties en ja de data wordt scrambled. Maar ik vind het knap dat ze dan kunnen bewijzen (of vermoeden) dat inderdaad de output data pseudo randomized is.

Ik denk niet dat je ooit kunt bewijzen dat iets "willekeurig" is. Want was is willekeurig? Pak nu een lijst met 100 keer een getal van 0 tot 1. Stel nu dat elke getal precies even vaak voorkomt. Is dat dan willekeurig? Nee zou je zeggen, elk getal komt precies even vaak voor. Dat kan geen toeval zijn. Dan neem je opnieuw een lijst. Dit keer heb je 30 keer het geval 10, en de rest is weer gelijk verdeeld over de anderer getalen? Is dit random? Nee, want 10 schiet er boven uit. Nu neem je een lijst met 100 getallen en het is ongeveer gelijk verdeeld .... 9 komt een paar keer meer voor, 7 een stuk minder, 5 precies gemiddeld. Etc etc.

Het probleem met "willekeurig" is dat mensen overal patronen in zien en waar ik geen patroon in zie zie jij misschien wel een patroon in.

Maar dan is er natuurlijk nog de wiskundige definitie van "willekeurig" namelijk: Het gebrek aan een patroon of voorspelbaarheid.

Maar als jij een regel text schrijft en ik zet die op de meest eenvoudige manier om naar getallen. Bijvoorbeeld a = 01, b=02, A= 27, B=28 enz enz.
Dan krijg je ook een lijst getallen waarvan de volgende niet zomaar te voorspellen zijn omdat niemand toch kan voorspellen wat jij gaat schrijven?

Maar dat is niet zo. In zo'n een textregel omgezet naar getallen zit namelijk wel een patroon. Een patroon die verraad dat het om de Nederlandse taal gaat. Immers bij scrabble krijgen sommige letters meer punten dan andere. Als je een analyse doet op een nederlands boek waar je gewoon elke letter van het alfabet telt en je vergelijkt die met een analyse van een ander boek waar je het zelfde doet. Op een paar uitschieters na zul je ongeveer dezelfde letter verdeling zien. Die is eigen aan onze taal.

En dus kunnen we concluderen dat willekeurigheid NOOIT 100% te defenieren valt. In het geval van letters die we omzetten naar cijfers zouden we een getallen lijst kunnen analyseren en concluderen dat de lijst inderdaad random is. Maar het zou best kunnen dat het gewoon een vreemde taal is waarvan wij niet weten wat de letter verdeling is.

Dat is dus het hele ding. Om echt te concluderen dat iets random is moet je de reeks getallen gaan controleren aan alle patronen en regels en verdelingsvormen en statistiek je maar kent.

En niemand kent ze allemaal.

Cryptografie werkt dus anders. Het werkt niet met willekeurigheid. Het merkt met het verstoppen van data IN willekeurigheid.

Zodat wij een analyse doet en wiskundig gezien onmogelijk achter kan komen wat de "garbage is" en wat de boodschap is.
En dat kan wiskundig inderdaad bewezen worden op een hele eenvoudige manier.

Als ik zeg 12 x 13 = 156 en ik geef je 156 en ik vraag je om mij te vertellen waarvan 156 de uitkomst is .... dan kun je echt van alles zeggen:

1+155?
2+154?
3+`153?
2 x 78?

En dat is wat brute force inhoud. Je voert willekeurige bewerkingen uit in volgorde en na elke uitkomst controleer je de uitkomst op patronen of op wat je zoekt.

In cryptografie heb je dus alleen maar wiskunde nodig waar je kunt bewijzen dat een bewerking makkelijk is uit te voeren in de ene richting maar heel erg moeilijk in de andere richting.

Een one way function.

Ik geef een voorbeeld in cryptografie waar je niet eens wiskunde voor nodig hebt.


Stel je hebt een lange lijst met boeken. Er staan er 10 000 op. Samen met je vriend kies je er eentje uit. Willekeurig. Gooi maar een dobbelsteen een keer of 6.

Je ziet dat je het boek twee keer hebt. Een keer jou en een voor je vriend. Nu gaat je vriend naar de andere kant van de wereld en jij blijft thuis.

Wanneer je veilig wilt communiceren dan doe je het als volg.
Je wilt bijvoorbeeld sturen: Het gaat goed met mij.

Dan neem je het boek en je begint met de eerste letter. Je volgt alle letters tot je de H tegenkomt en noteert de hoeveelste letter het is in de text. Bijvoorbeeld letter 130. Dan kijk je verder tot je de letter e tegenkomt. Die staat op nummer 140. Enz enz. Elk nummer zal groter zijn dan het vorige.

Die nummers stuur je naar je vriend en die doet gewoon het omgekeerde.

Dit concept noemt met een One-time pad -->http://en.wikipedia.org/wiki/One-time_pad

Het is de enige vorm van cryptografie die 100% onkraakbaar is.
Maar dan moet je de regels wel goed volgen. Wanneer jij en je vriend uitgepraat zijn of wanneer het "boek" op is .... dan mogen ze niet opnieuw starten. Nee, ze moeten een nieuw boek afspreken en dan opnieuw beginnen. En wanneer ze door alle 10 000 boeken zijn geweest moeten ze een andere lijst met boeken maken. En daar mag geen enkele keer hetzelfde boek opstaan.

Zie je waar ik naar toe wil?

Een one time pad werkt alleen als je random stream even lang is als je booschap. En je hebt constant een nieuwe randomstream nodig.

Hoe zou je dit nu zonder boeken kunnen doen? Stel dat je een computer systeem hebt die je random data geeft. Hoe kun je twee zulke systemen hebben die exact dezelfde random data geeft?
Dat kan alleen als er een patroon in zit.
Of ... nog leuker .... als je je random data van precies dezelfde plaats haalt.

Jij en je vriend zouden bijvoorbeeld een instrument op exact hetzelfde plekje van de zon richten. En die input gebruiken als random data. Eerst zou je dan een lange test moeten doen. En je vriend mag niet aan de andere kant van de wereld zitten. Jullie kunnen alleen maar de random data van de zon gebruiken als alle twee de kanten die kunnen opnemen om later te gebruiken.

En je systeem is ook niet onkraakbaar meer ... want als iemand uitvind waar je precies je instrument op richt dan kunnen ze meeluisteren.

En op dit soort principes is cryptografie gebouwd.

En enigma machine is exact hetzelfde! Alleen zitten nu al die boeken in de machine zelf ... zijn de boeken veel en veel korter .... en is er van te voren met iedereen een lijst afgesproken van welk boek wanneer gebruikt word.

De Alies hebben hier alleen maar door heen kunnen breken omdat de axis hun one-time-pad niet 100% op de juiste manier toepasten. Die kleine foutjes hebben er uiteindelijk toe geleid dat de code gebroken werd. Elke keer als ze zo'n klein foutje in een radioboodschap onderschepte dan konden ze alles ongedaan maken.

In de cryptografie die we nu hebben worden one time pads ook nog wel gebruikt maar meestal is dat niet practisch.

Ik wil ook kunnen communiceren met iemand die ik nog nooit hebt ontmoet om samen een geheime sleutel mee af te spreken (Welk boek). En als ik deze lijst met boeken eerst doorstuur .... wat als iemand die lijst onderschept? Vergeet niet ... Eve is always listening!

Dit soort problemen zijn langzaam door briljante wiskundige opgelost.

Modular arithmetic, priemgetallen, Discrete Logarithms, Integer Factorization , Elliptic Curves, dit zijn allemaal wiskundige "tools" die gebruikt kunnen worden voor ingenieuze puzzels en sloten.

Nooit kan er van te voren bewezen worden dat iets 100% onkraakbaar is. Tenzij het een perfect uitgevoerde one time pad is. Maar die is dus niet practisch op het internet.

Maar wat wel bewezen kan worden is dit: In de ene richting de bewerkingen uitvoeren kost een cpu een minimale inspaning. In de andere richting de bewerking uitvoeren een maximale inspanning ... tenzij je het geheim kent. De sleutel.

En zo zit je bij getallen als 2 tot de macht 256. Je kunt nog niet eens van 0 beginnen te tellen en eindigen bij 2 tot de macht 256 voor onze zon helemaal dood is.

Dus veel geluk met bruteforce. De enige manier waarop goede cryptografie uiteindelijk word gekraakt is wanneer het niet 100% de regels volgt en er dus ergens foutjes zitten die uitgebuit kunnen worden.

Dat brengt ons bij het volgende probleem: processors en willekeurigheid.

Mensen zijn een stuk beter in randomness dan computers.
Deze tekst ... ook al zit er een patroon van de Nederlandse taal in en een patroon van hoe ik schrijf is vrij random, Want niemand of niks in de wereld had precies kunnen voorspelen wat ik allemaal ging schrijven. Had ik iemand de eerste regel gegeven dan had die persoon nooit de rest kunnen voorspelen. Miscchien door de patronen van de Nederlandse taal toe te passen en mijn vorige schrijfsels te analyseren en het onderwerp mee te nemen zou het mogelijk zijn om een percentage juist te voorspelen.

En daar zit de scheidslijn. Als jou cryptografie onbreekbaar is als 10% van de data random is .... en breekbaar begint te zijn als het maar 9% random is. Dan kun je dit in de wiskunde bewijzen tot op een zeker foutmarge. De kunst is dus om genoeg marge over te hebben en dan kun je dus wiskundig bewijzen dat je cryptografie onbreekbaar is.

Zo is er dus perfect cryptografie mogelijk is onbreekbaar is.
Maar dat concept moet dus ook uitgewerkt worden in software, het moet practisch zijn, je CPU moet aan de regels van de random generatie voldoen .... etc etc. Ook maar een kleine foutje in het volgen van jou super precieze regels en er zit een zwakte in de UITWERKING van je algoritme.

En dit zijn dus twee manier waardoor wiskundige cryptografie gebroken word

1 --> one time pad die alle regels volgt --> onbreekbaar
2 --> algortime dat wiskundig bewezen is --> onbreekbaar en niet te brute forcen omdat de wiskundige hooiberg groter is dan ons zonnestelsel
3 --> algoritme dat wiskundig bewezen is maar in je bewijs zit een foutje --> foutje worden gevonden --> er word als nog bewezen dat het wiskundig veilig is --> niks aan de hand --> er word bewezen dat het niet wiskundig veilig is --> nu is het breekbaar
4 --> algortime dat wiskundig bewezen is --> geen fouten te vinden in bewijs --> iedereen neemt aan dat het veilig is tot iemand ooit een foutje vind --> maar in de uitwerking van het algoritme worden fouten gemaakt --> uitwerking kan worden uitgebuit --> je systeem is alleen maar onkraakbaar als een uitwerking perfect de regels volgt --> 10% van de tijd is dat niet het geval --> 10% van de tijd kan het dus gekraakt worden --> informatie van een kraak kan gebruikt worden om de andere 90% OOK te kraken, binnen een bepaalde uitwerking. Bijvoorbeeld VOIP van SKype is versleuteld met systeem A en VOIP van Voipbuster versleuteld met systeeem A. Maar voip van skype gebruikt uitwerking A en voip van voipbuster gebruikt uitwerking B. In uitwerking A zit een klein foutje, in uitwerking B niet.

Net als een klein beetje speling in een knoop kan uitwerking A ontraffelt worden tot 100% van de informatie gekraakt kan worden terwijl systeem A perfect waterdicht is.

En zo kunnen we bezig blijven.

Geheime sleutel op harde schijf maar geheime sleutel niet versleuteld met andere sleutel? Computer kan gehackt worden en geheimge sleutel kan uitlekken --> breach

Geheime sleutel op harde schijf versleutelt? --> versleutelde geheime sleutel word gehackt ---> versleuteling van geheime sleutel kan gebrute forced worden --> geheime sleutel is gehackt.

Enz enz enz. Een perfect uitgevoerde one time pad heeft hier ook een zwakte. Vind persoon A die met persoon B via het geheime boek communiceert en martel hem tot hij zegt welk boek er gebrukt word. Als persoon B nu ook met persoon C communiceert via HETZELFDE boek dan kan die communicatie onderschept worden omdat persoon A compromised is.

En dus heb je wiskunde waarvan bewezen kan worden dat het 100% veilig is. Maar van mensen kan dat dus nooit. En het zijn nog steeds mensen die software schrijven met foutjes in een mensen die hardware maken met foutjes in.

Wiskunde = perfect = kan bewezen worden --> al de rest is vertrouwen.

Tot daar ... hoop dat het een beetje te begrijpen is. Al snap ik niet al de wiskunde. De concepten, de ideeën, die kan iedereen snappen.

Die kans is 2³⁴⁸⁰ keer groter, maar eigenlijk doet het er niet zo toe hoeveel groter de kans is. Wat er wel toe doet is hoe klein 1 op 2²⁵⁶ is. Zelfs met 1 gok per Planck tijd (10^-43s, theoretisch de kleinst mogelijk meetbare tijdseenheid), zul je nog 10³⁴ seconden oftewel 10²⁶ jaar nodig hebben om de hele keyspace af te gaan - vele malen meer keer de huidige leeftijd van het universum. Als je de wetten van de thermodynamica erbij haalt dan zul je zien alle energie van de zon niet genoeg is om tot 2²⁵⁶ te kunnen tellen.

(
Landauer's principle stelt dat er minimaal 2,85e-21 J nodig is voor een elementaire operatie. De totale massa-energie van de zon is 1.8e47 J. Met die energie kun je dus 10⁶⁸ operaties doen, dat is ongeveer 2²²⁵
)

Nou zou je Grover's search toe kunnen passen op een kwantum computer die opereert in O(√n), waardoor je dus maar 2¹²⁸ operaties hoeft te doen. De energie in de zon is daarvoor genoeg, maar voor nog een lange tijd buiten het bereik van de mensheid.

AES heeft overigens helemaal niets te maken met factorizatie. Het is een block cipher en heeft zo zijn eigen problemen, die helemaal niet toepasbaar zijn op cryptografie middels elliptische krommen.

Bottom line is dat een brute force attack op 256 bits hoe dan ook ondoenlijk is. Niet alleen nu, maar voor de voorzienbare toekomst, en waarschijnlijk voor altijd. En de stap naar 512 bits is natuurlijk gemakkelijk gemaakt.

[Reactie gewijzigd door .oisyn op 30 januari 2014 12:01]

Je aanname is dat er niemand op de planeet knapper is dan jij.

Nee, mijn aanname is dat onze huidige kennis van de limieten van de natuurwetten redelijk accuraat zijn, en dat is een aanname waar ik al mijn hebben en houden wel voor in durf te zetten. Jouw hele redenatie gaat helemaal niet over AES op zich (want de originele door jouzelf gestarte discussie ging erover dat ECDH in jouw ogen helemaal niet veiliger was dan RSA), maar over het aantal bits dat je af moet lopen. Je stelt dat een 4096 bits sleutel per definitie veiliger is dan een 256 bits sleutel omdat er veel meer mogelijkheden zijn. Dat is nog afgezien van het feit dat het gebruikte algoritme weldegelijk uitmaakt een nonargument, aangezien ik heb aangetoond aan dat brute force bij een 256 bits sleutel al ondoenlijk is.

Dat AES verder last heeft van andere issues gaf ik ook al aan, en zo zijn er voor ECDH en RSA ook attacks die niet op brute force gebaseerd zijn maar op wiskundige principes. De reden dat er voor RSA een orde van grootte meer bits wordt gebruikt dan ECDH (~2000 vs ~200) heeft alles te maken met het gebruikte algoritme en de attacks die bekend zijn, namelijk het oplossen van het factorisatieprobleem, wat wel sneller te doen is dan O(2^N).

[Reactie gewijzigd door .oisyn op 30 januari 2014 17:16]

Ik begrijp je punt niet helemaal. Je zegt alleen dat gokken een slecht schalend algoritme is.

Verder is zelfs gokken op een 256-bit getal belachelijk. Ter vergelijking, 2^256 ~ 10^77. Gokken op een getal van die omvang komt ongeveer neer op het aanwijzen van een kubieke meter ergens in het zichtbare heelal (~10^80 m^3).

Het kan zo zijn dat 4096-bit RSA veiliger is dan bijv. 256-bit ECC. Maar bij dat laatste is de encryptie een stuk gemakkelijker (dus is er minder energie nodig om een boodschap te beveiligen), waardoor het (vooralsnog) haalbaar blijft om cryptografie op grote schaal en nagenoeg alle devices toe te passen.

Voor onderzeeërs echter is veiligheid natuurlijk net even wat belangrijker dan hoe snel de boodschap overkomt...

Persoonlijk hou ik van meer volledige beschrijvingen, (relatief) korte beschrijvingen roepen bij mij soms meer vragen op dan worden beantwoord. Bekijk de colleges van deze persoon maar eens, deze colleges hebben mij meer duidelijk gemaakt dan al die korte beschrijvingen bij elkaar.

https://www.youtube.com/user/kirankuppa/videos

Gewoon helder (op zijn Duits) uitgelegd. Niet alleen ECC wordt behandeld, maar ook alle andere crypto algoritmes.

Bedankt voor de link. Deze colleges zijn veel beter dan degene die ik heb gevolgd (voor zover ik kan zien na alleen het bekijken van het college over MITM aanvallen op public key protocols).

Je kunt een dergelijke uitspraak niet op zichzelf nemen en het beschouwen als een uitspraak met absolute zekerheid voor nu tot in de eeuwigheid.

Zoals gebruikelijk wordt hier stilzwijgend bedoeld "voor zover wij nu weten, naar de unanieme mening van alle experts op dit gebied".

Inderdaad, het zou zomaar kunnen dat er toch nog nieuwe inzichten ontstaan die de situatie veranderen. Maar aangezien we die op dit moment toch niet kunnen voorspellen kunnen we er ook geen rekening mee houden in de huidige encryptie implementaties.

Wat wel kan is er voor zorgen dat, als er een probleem met de encryptie blijkt te zijn, je gemakkelijk en snel om kunt schakelen naar iets anders, maar dat is meer een organisatorisch/planning ding.

[Reactie gewijzigd door locke960 op 30 januari 2014 10:40]

Als je kunt factoriseren dan kun je public key elliptic curve methodes ook kraken dus, WANT DAT IS HETZELFDE. Elliptic curves worden dan ook ingezet om te factoriseren.

Dat klopt, deze problemen vallen allemaal onder de grote paraplu "NP volledige problemen" en als je voor 1 probleem een snelle oplossing vind, dan heb je voor al deze soort problemen een snelle oplossing.

De statistische kans dat je 256 bits goedgokt is tenslotte groter dan de statistische kans dat je 8192 bits goedgokt.

Dit is dan weer onzin, want het is volledig afhankelijk van de gebruike algorithmen. Sommige algorithmen hebben extra wiskundige eisen, (bijvoorbeeld: er bestaan twee priemgetallen p en q, en p*q is je sleutel), en door deze wiskundige eisen neemt het aantal sleutels af. Dan moet je dus een grotere keyspace hebben (meer bits dus) om dezelfde hoeveelheid sleutels te maken.

Stel dat jij een willekeurige sleutel kiest, een getal onder de 100. De kans dat ik dat in 1 keer goed gok is dan dus 1%. Als we nu als extra eis opnemen dat jouw sleutel door 3 deelbaar moet zijn, dan heb je nog maar 33 beschikbare sleutels, en dan is mijn kans dus 3%. Jij moet een sleutel onder de 300 kiezen wil je de kans weer terugbrengen naar 1%.

Dat klopt, deze problemen vallen allemaal onder de grote paraplu "NP volledige problemen" en als je voor 1 probleem een snelle oplossing vind, dan heb je voor al deze soort problemen een snelle oplossing.

Factorisatie is wel NP maar (voor zover bekend) niet NP-moeilijk en dus ook niet NP-volledig. Hetzelfde geldt volgens mij voor de problemen die aan de grondslag van ECC liggen.

Jij hebt het over priemfactorisatie, en dat is iets TOTAAL anders dan de "factorisatie" waar het bij elliptische discrete curven om draait. Die twee hebben echt geen bal met elkaar te maken, je haalt weer eens van alles door elkaar

Factorisatie is polynomiaal.

Dat bewijs is allang geleverd. Het is echter niet simpel om het met huidige generatie computers en RAM polynomiaal te doen.

Er is echter in een hutje in India een paar jaar geleden een algoritme gevonden om priemgetallen polynomiaal binnen ongeveer O ( n ^ 10 ) te bewijzen (running time al veel sneller ondertussen dan dat).

Je haalt nu een aantal dingen door elkaar. Priem en factorisatie zijn heel verschillende problemen.

Bepalen of een bepaald getal priem is is inderdaad polynomiaal. Daaruit volgt echter niet, dat factorisatie ook polynomiaal is, want het gaat om twee verschillende problemen. Of factorisatie polynomiaal (in P) is of niet, is niet bekend. Met vermoedt over het algemeen dat het niet polynomiaal is (maar dat vermoedde men tot tien jaar geleden ook van het priemprobleem).

Het inzicht is dus logisch dat als je kunt bewijzen dat je polynomiaal een getal priem kunt bewijzen, dat je dan ook polynomiaal een getal kunt factoriseren (niet gezegd dat dit O ( n ^ 10 ) is - dat is weer hele andere discussie).. Dus met relatief "weinig" ram en relatief 'weinig' computersnelheid.

Zo logisch is dat inzicht niet, want in tien jaar is er nog niemand in geslaagd het te bewijzen.

Ik weet niet of de vergelijkingen tot je doordringen, maar goed. Wat je zegt klopt. Op *die* manier kraak je AES sneller. Gaan we even terug naar het voorbeeld van Omegium.
We pakken voor AES een key van 10 bits, dus een getal onder de 1024. Je hebt maximaal 1024 pogingen nodig om de key te kraken.
We pakken voor RSA een key van 11 bits, dus een getal onder de 2048. Eis aan dat getal is dat het deelbaar door 4 moet zijn. Als je dom bent heb je 2048 pogingen nodig ('veiliger'), als je de eisen aan de sleutel uitbuit heb je er nog maar 512 over. Je sleutel is effectief dus maar 9 bits lang maar er wordt wel over 11 bits gesproken.
Wat is nu veiliger?

Bottom line: het aantal bits bepaalt niet hoe veilig iets is. Het is niet voor niets dat er vergelijkingen zijn tussen algoritmes, zo van algoritme a met x bits is equivalent aan algoritme b met y bits.

Volgens mij is mijn post niet versleuteld dus het is me een raadsel waarom je er wel op reageert maar er niet op ingaat.

het is nog steeds niet polynomiaal op de huidige generatie computers

Ik hoop dat je je realiseert dat het al dan niet polynomiaal zijn van de looptijd van een bepaald algoritme om een bepaald iets te kraken werkelijk volkomen losstaat van 'generaties computers' of computerkracht in het algemeen?

Daarentegen verzint een Belg een algoritmetje voor de NSA een jaar of 10 terug, dat wordt dan de AES standaard, en vervolgens gaan ze claimen dat dit VEILIGER is dan RSA?

Waarom zou dat niet kunnen? Als ik nu 'even' een algoritmetje verzin wat eerst RSA doet en daarna ROT13 (of AES voor mijn part, of nog een keer RSA), dan zou je daarvan al kunnen zeggen dat het veiliger is (zitten wat haken en ogen aan). Heb ik zojuist in de trein, deze reactie typende, verzonnen. Goed, verder is dit voorbeeld eigenlijk niet eens zo relevant maar het kan best dat iemand iets beters verzint.

Ik heb trouwens een beter idee. Ik genereer een 16384-bits key, daarvan gooi ik 16128 bits weg en de resulterende 256-bits key gebruik ik om met AES iets te versleutelen. Dat algoritme noem ik DGAES en aangezien de key 16384 bits heeft is het veiliger dan RSA!
Nogmaals: algoritme A met keylengte X (maar wat vanwege eisen aan de key, zoals bij RSA, een effectieve keylengte Z heeft) is niet per se veiliger dan algoritme B met keylengte Y als X>Y en vooral niet als Z<Y..

Nee.

Bij AES kan je inderdaad 256 willekeurige bits pakken.

Bij RSA (en ook bij Diffie-Hellman, en ik ben voor 99% zeker van Eliptic Curve), moet die verzameling bits aan bepaalde eisen voldoen. Niet ieder getal onder de 4096 bits is bruikbaar, want in de meeste gevallen zal je algorithme niet meer werken. Het gaat om het aantal mogelijke sleutels, niet om het aantal bits. En daarom kan je niet zomaar stellen dat meer bits == beter.

Nu kunnen we er gevoeglijk vanuitgaan dat alle public key algoritmes in feite polynomiaal kraakbaar zijn.

Als dat zo is dan maakt het niet zo heel veel meer uit of je 256, 2048 of 32768 bits gebruikt. Da's een kwestie van iets meer computing power erin steken, want je kan het toch wel in polynomiale tijd oplossen. Bovendien is de "factorisatie" bij ECC een compleet andere tak van sport, en een algoritme om het ene op te lossen zal niet werken bij de andere. Het is niet voor niets dat je voor ECC minder bits nodig hebt voor dezelfde mate van veiligheid als RSA, ongeacht wat jij erover loopt te beweren (en daarbij allerlei zaken door de war haalt)

.edit: na wat verder gelezen te hebben blijkt dat je eigenlijk helemaal niet snapt wat het integer-factorisatie probleem inhoudt, want dat is voor zover we weten niet polynomiaal, alleen bestaat daar geen bewijs voor. Op het moment dat bewezen wordt dat het wel polynomiaal is dan heb je niets meer aan RSA. En dit treedt al in werking bij de eerste goed werkende kwantum computer.

[Reactie gewijzigd door .oisyn op 30 januari 2014 21:57]

"De stelling geponeerd was dat Elliptic curve gebaseerde encryptie VEILIGER is dan RSA.

Mijn bewering is dat dit complete onzin is."

Ik durf het bijna niet te vragen, maar waar is je harde wiskunde dan om dit mee te onderbouwen?

Dan pakken we er 4096 random uit voor RSA.

Die zijn dan hoogstwaarschijnlijk ongeschikt, want een RSA key heeft sterke restricties. "Random" gaat niet op hier, bij AES wel.

1 klein algoritmetje en HOPPA dat AES is weg.

Nope, alleen als je key kwetsbaar is. Met 256 bits entropie (dus niet minder wegens een zwakke random generator of hash functie) wordt dat nooit gekraakt.

Waar is je bewijs dat random opgaat voor AES?

Zie beschrijving van AES waar je kunt zien dat voor de 256-bit keys geen restricties gelden, kortom iedere (dus ook random) input van 256-bit volstaat als key. Bovendien worden in de praktijk bij AES custom encryptie passwords (die niet noodzakelijkerwijs 256-bit zijn) naar 256-bit omgezet via een hash, en die zijn per definitie pseudo-random.

Zulke restricties zijn er bij RSA overduidelijk wel, daar voldoen alleen grote priemgetallen.

Zoals elders ook al vermeld, is het volstrekt onrealistisch dat een sample space van 2^256 ooit helemaal doorzocht kan worden, laat staan dat dit snel kan.

[Reactie gewijzigd door Lord_Farin op 30 januari 2014 11:50]

Kom maar met bewijs dat je 2⁸¹⁹² moet doorzoeken voor RSA8192. Dat is namelijk de volledige basis van je eigen argument.

Lever jij eerst maar eens een BEWIJS dat 2048-bits RSA veiliger is. Aangezien je je nogal vastklampt aan theoretische gevallen, zou het zomaar kunnen zijn dat het factorisatieprobleem wordt opgelost (dmv een werkende kwantum computer is op dit moment de meest reële mogelijkheid). Daar sta je dan met je gebroken algoritme die zogenaamd veiliger was, terwijl AES hier helemaal geen last van heeft.

Het enige wat je met de huidige kennis van zaken kunt stellen is dat een brute force attack voor 2²⁵⁶ mogelijkheden al voldoende wordt afgeweerd voor de voorzienbare toekomst (dat is fundamentele natuurkunde waar je voor zover we weten niet omheen kunt). Als je hypothetische gevallen erbij gaat halen dan kun je sowieso niets zeggen of het ene algoritme veiliger is dan het andere, en de grootte van de keyspace is daarbij volstrekt irrelevant.

[Reactie gewijzigd door .oisyn op 30 januari 2014 17:25]

Als je kunt factoriseren dan kun je public key elliptic curve methodes ook kraken dus, WANT DAT IS HETZELFDE.

Het factoriseren van priemgetallen is echt TOTAAL iets anders dan bij elliptic curves. Het heet om semantische redenen allebei "factoriseren" (wat je zou begrijpen als je thuis bent in deze twee takken van wiskunde) maar daar houdt de overeenkomst wel ongeveer op. Het lijkt echt in de verste verte niet op elkaar.

Hey anders gebruik je toch ROT32768? Dat is 4 keer moeilijker te kraken dan RSA8192, doe de wiskunde maar.

ECC is een puur discreet logarithme probleem, welliswaar niet zo klasiek als factorisatie, maar het scheelt niet veel.

Zowel het discrete logarithme probleem als factorizatie zitten in NP (polynomiaal verifieerbaar) en voor beide zijn geen polynomiale oplossingen bekend (dus voor zover bekend niet in P).

Claimen dat polynomiaal verifieerbaar betekent dat het ook polynomiaal oplosbaar is, is nogal een claim. Dat is het klassieke P = NP vraagstuk. Jij schaart je achter de kleine groep aanhangers die gelooft dat P = NP. Dat is je goed recht. De algemene consensus is dat P /= NP, maar hierover discussieren heeft niet zoveel zin hier, een bewijs voor 1 van beide stellingen is 1 van de millenium prize uitdagingen en een miljoen waard (en waarschijnlijk ook het equivalent van een nobelprijs in de wiskunde of informatica).

Op dit moment is voor integer factorizatie een sub-exponentieel, maar wel super-polynomisch algorithme bekend (met een nogal ingewikkelde big-O complexiteit).
De records bij het discrete log probleem worden momenteel gezet met een algorithm van orde O(sqrt(n)), dus exponentieel in de helft van het aantal bits van de groepsgrootte n.

Dit verschil, sub-exponetieel vs exponentieel, maakt het verschil in de aan te raden keysize.

Discussieren met jouw lijkt verder voornamelijk een alu-hoedjes aangelegenheid, dus voor mij verder niet erg zinvol.

[Reactie gewijzigd door RickN op 31 januari 2014 10:30]

Ja maar ROT32768 heeft 4 keer meer bits dan RSA8192 en dus is het 4 keer zo veilig. Je zei het eerder zelf

Kortom, minder bits maakt de zaak dan alleen gevaarlijker.

Dus waarom RSA8192 in plaats van ROT32768? ROT32768 heeft 4 keer meer bits dan RSA8192 en het werkt met factorisaties van 26!

Lees hier hoe het allemaal begon met ROT13 en later 2ROT13, nadat elementaire primologische fouten in de wiskunde achter de wiskunde werden gevonden in RSA1 en later in RSA2 all the way tot en met RSA8192. (hebben ze wel meer dan 9000 dagen over gedaan, die luie wiskundigen)

Punt is van alle algoritmes is RSA8192 het enige algoritme dat de 'test of time' heeft doorstaan maar ROT32768 is het enige dat ook bescherming bied tegen tijdreizigers. En waarom zou je dat risico nemen met je gevoelige data (pr0n en zo)? Je bent gek als RSA8192 gebruikt want je kunt op een paar uur tijd tellen tot 8192, dus met een simpel mobieltje van een tijdreiziger kun je er al doorheen breken.
Nee ROT32768 is de enige vorm van encryptie DIE GENOEG BITS HEEFT. ALLE ANDER HEBBEN GEWOON TE WEINIG BITS. TE WEINIG ZEG IK U! TE WEINIG! BITS BITS BITS. TE WEINIG BITS. ZE HEBBEN TE WEINIG BITS. AARARHHARHAHRAHRHAHRHAR

[Reactie gewijzigd door Kain_niaK op 1 februari 2014 23:00]

Mag ik even melden dat de winnaar van deze comment-sectie toch wel hardwareaddict is?

Los van het feit dat het mij gewoonweg aan de inhoudelijke kennis ontbreekt om te bepalen of hardwareaddict een encyptie-meester is, er wel iets van weet, of gewoon random onzin loopt uit te spuiten, heeft hij toch als ik het zo zie iedereen - voornamelijk .oisyn - op de kast.

Wat leren we van dergelijke mensen? Niet op reageren.

Juist wel, want zo maak je mensen nieuwsgierig. Ik zit nu al een paar uur de youtube filmpjes die in dit topic gepost zijn te bekijken. Allemaal zeer leerzaam. En hardwareaddict is niet aan het trollen, gewoon aan het opscheppen/interessant aan het doen met technobabbel. Misschien leert hij vandaag ook iets. De comment sectie op d eFP is de verkeerde plaats om dingen neer te plempen die volledig of gedeeltelijk onwaar zijn, daar zit er teveel nuchtere Hollanders voor op Tweakers. .oisyn is volgens mij een kundig programmeur ... ik lees altijd met veel plezier zijn comments. Feitelijk haal ik meestal meer informatie uit comments op de nieuwsberichten dan de berichten zelf. En ook meer entertainment.