Overleg:Encryptie

Uit Wikipedia, de vrije encyclopedie
Ga naar: navigatie, zoeken

N.B. Veel van dit overleg heeft betrekking op informatie uit het artikel, die inmiddels is verhuisd naar andere artikelen rond dit onderwerp. Joachim 11 mrt 2006 14:45 (CET)

Het bestaan van een "achterdeurtje" in het DES-algorithme is allerminst zeker. De specificatie's van DES zijn vrij beschikbaar, dus voor iedereen te lezen en bestuderen. Daardoor kan een geheime dienst er niet van op aan dat zo'n achterdeurtje verborgen blijft. Er zijn tenslotte vele slimme en gemotiveerde hackers op de wereld. Zo'n achterdeurtje is derhalve tamelijk onwaarschijnlijk.

Er is echter een ander punt wat reeds bij de allereerste publicatie van DES als fundamentele zwakte werd bekritiseerd. Dat is de geringe sleutel-grootte, welke slechts 56 bits bedraagt. Dat maakt dat een instantie met voldoende geld en computervermogen simpelweg alle mogelijke sleutelwaarden kan proberen.

Inmiddels is er een opvolger van DES, het z.g. Rijndael algoritme, ook wel AES genaamd. Deze heeft een variabele sleutelgrootte tot 256 bits.

Jos van Kesteren: 1 September 2003

Ik schreef dit eigenlijk met in het achterhoofd de gedachte dat de geringe sleutelgrootte het achterdeurtje was: iemand met voldoende computerpower (dedicated processors etc) waar we de CIA toch wel toe mogen rekenen kan het gewoon kraken. Bart Evanherk 1 sep 2003 22:20 (CEST)

Dat is m.i. geen achterdeurtje, maar domme brute force tegen de voordeur aan waarmee het gekraakt wordt. Flyingbird 1 sep 2003 22:36 (CEST)

Toch is een achterdeur niet ondenkbaar. DES maakt namelijk gebruik van zogenaamde substitutieboxen. De inhoud van die substitutieboxen (S-Boxen)is bekend, maar de makers van het protocol hebben nooit verklaard waarom de inhoud moet zijn zoals hij is. Daarmee voldoet het DES-versleuteling strikt genomen ook niet aan het principe van Auguste Kerckhoffs von Nieuwenhoff dat stelt dat de sterkte van de versleuteling slechts af mag hangen van de sterkte van de sleutel en niet van het gebruikte algoritme, omdat de kennis van het algoritme moet kunnen worden verspreid. De verklaring voor de inhoud van de S-Boxen is nooit openbaar gemaakt, en daarom kan het vermoeden dus wel degelijk bestaan dat bepaalde organisaties via een echte achterdeur toegang hebben tot de berichten. Jan Arkesteijn 1 sep 2003 23:04 (CEST)

Interessant! Leuke informatie voor het artikel zelf, lijkt me.
Voor een encyclopedie gaat het misschien wat te diep, en omdat de achterdeur niet bewezen is, neigt het naar opinie, wat voor Wikipedie niet is toegestaan. Een artikel over Auguste Kerckhoffs von Nieuwenhoff zou niet slecht zijn. Het is een Nederlandse onderzoeker wiens naam in de encryptiewereld tot het standaard lesmateriaal behoort. Maar ik weet te weinig van hem. Wie wel? Jan Arkesteijn 2 sep 2003 09:14 (CEST)
Die S-boxen werden, als ik het goed herinner, ontworpen door de NSA. IBM heeft deze dan geimplementeerd. Inderdaad was er toen niemand (buiten de NSA) die begreep waarom de S-boxen net die vorm gekregen hadden. In de jaren '80 ontdekten twee Israelische wiskundigen een nieuw principe (helaas ben ik vergeten wat juist), waaruit bleek dat die S-boxen blijkbaar zo ontworpen waren dat een aanval op het algoritme moeilijker was. Met andere woorden: niet alleen had de NSA begin de jaren '70 al een kennis die zo'n 15 jaar vooruit was op de rest van de wereld, ze maakten het algoritme ook nog betrouwbaarder. --Viv3210 17 jun 2006 16:13 (CEST)
Dat vind ik een vreemd principe. Als de sterkte van de versleuteling slechts afhangt van de sterkte van de sleutel en niet van het gebruikte algoritme, waarom gebruiken we dan nog een ander dan het eenvoudigste algoritme? Volgensmij hangt de sterkte sowieso van het algoritme af - sommige algoritmen hebben duidelijke methoden van kraken, bij andere is er geen betere methode bekend dan simpelweg kraken. Andre Engels 1 sep 2003 23:25 (CEST)
Het eenvoudigste algoritme, bijv. ROT13 ;-), kan het toch niet toelaten dat je met een sterkere sleutel een veiliger algoritme krijgt? Met de open source implementaties van encryptie-algoritmen moet het haast wel in de sleutel zitten, lijkt me? Maar het is inderdaad de combinatie algo-sleutel die het sterk maakt. Flyingbird 1 sep 2003 23:36 (CEST)

Jullie hebben gelijk. Ik heb het te snel en uit de losse pols opgeschreven. Het principe van Kerckhoffs stelt dat de veiligheid van de versleutelde info niet mag afhangen van de geheimhouding van de het algoritme, maar alleen van de geheimhouding van de sleutel. De sterkte van het versleutelingsalgoritme maakt het natuurlijk wel moeilijker om een bericht te kraken, maar het algoritme moet natuurlijk algemeen bekend zijn. Alleen de sleutel moet de veiligheid van de gegevens waarborgen. Dat de Amerikaanse overheid DES kritiekloos als standaard protocol heeft geaccepteerd, en dat ook in een tijd dat de brute-force methode voor decoderen praktisch niet mogelijk was, geeft te denken. Jan Arkesteijn 2 sep 2003 09:02 (CEST)

Overigens zijn "geheime deurtjes" in versleutelingssoftware ook om een andere reden niet ondenkbaar. Softwareontwikkelaars moeten mogelijkheden hebben om protocollen te testen. Simpel vaststellen dat de uitkomst niet dat is wat je verwacht is dan niet voldoende. Dus tijdens de ontwikkeling worden op alle niveaus testpunten aangebracht. Je mag dan maar hopen dat die bij de uiteindelijke release ook allemaal verwijderd zijn. Jan Arkesteijn 2 sep 2003 09:05 (CEST)

In versleutelingssoftware: Ja, in algoritmes: Nee. --Viv3210 17 jun 2006 16:19 (CEST)

Bij een goede opzet van de toepassing is er slechts 1 compiler switch nodig om alle debug statements uit te schakelen voor de productie versie. En je mag hopen dat professionele organisaties een standaard testplan hebben voor hun toepassingen voor ze een neiuwe release of patch uitbrengen, waarin dit aspect is meegenomen. Overigens zijn eventuele achterdeurtjes in open source software niet aanwezig of bekend. Het lijkt me goed om een paragraaf over export bepalingen (was 128 / 256 bits encryptie toen ik me een paar jaar geleden er in verdiepte) van europa en de states in het artikel op te nemen, maar ik ben daar te veel uit om het zelf te doen. TeunSpaans 2 sep 2003 09:51 (CEST)

Overigens vind ik persoonlijk de term kraken te populair, de normale vakterm was een paar jaar geleden cryptoanalyse. Maar misschien is dat een anglicisme? TeunSpaans 2 sep 2003 10:10 (CEST)

Cryptoanalyse is correct, maar niet volledig (vind ik). Met cryptoanalyse gaat men proberen een tekst te decrypteren zonder de volledige sleutel te kennen (dus geen brute force attack), maar door zwakheden in het algoritme te gebruiken. Een voorbeeld is XOR met beperkte sleutellengte. --Viv3210 17 jun 2006 16:19 (CEST)

Zowel bij symmetrisch als asymmetrische systemen zal de sleutel naar de ontvanger moeten gaan, dus opvoeren als voordeel van asymmetrische crypto dat er geen sleutel héén hoeft, begrijp ik niet. Groot voordeel van symmetrisch is dat er één sleutel is, maar groot voordeel van asymmetrisch is het kunnen scheiden van codeer en decodeer mogelijkheden, door beperkte verspreiding van de sleutel. Ook zeer geschikt voor one-to-many verkeer, want alleen de zender heeft dan de codeer sleutel (authentification).

Voorstel: voordelen/nadelen herzien. Gezien het uitgebreide artikel wilde ik er niet in 'krassen'. Ik ben wel de auteur van o.a. asymmetrische cryptografie bladzijde. De symm volgt zsm. panthouse 22 okt 2003 23:32 (CEST)

Het is maar hoe je het leest, Panthouse. Bij asymmetrische versleuteling werken beide partijen met een verschillende sleutel, terwijl bij symmetrische versleuteling beiden met de zelfde sleutel werken. Dus bij dat laatste is daadwerkelijk sprake van uitwisseling. Bij asymmetrische systemen is er slechts sprake van het ophalen van de publieke sleutel. Maar is dat ook uitwisseling? Jan Arkesteijn 23 okt 2003 12:36 (CEST)
Nee hoor. Beide systemen hebben voor- en nadelen. Het enige wat een rol speelt is de toepassing. Je hoeft niet noodzakelijk berichten naar een ander encrypteren. Het heeft bijvoorbeeld weinig zin om bestanden die je wilt confidentieel op je eigen pc bewaren met een asymmetrisch algoritme te gaan beschermen. Een echt nadeel van asymetrische encryptie is dat het veel en veel trager is. Misschien dus nog vermelden dat het sturen van berichten met een hybride encryptie gebeurt? --Viv3210 17 jun 2006 16:19 (CEST)
Vanuit die redenatie heb je gelijk, maar dat geldt alleen in gevallen dat bij assymmetrische crypto gekozen wordt om één sleutel publiek te maken. Dit is niet in alle gevallen het geval. Er zijn toepassingen waarin het oppperbevel de ene sleutel heeft en de troepen de 2e. Zo kan alleen het opperbevel de commando's geven. Muitende troepen of verslagen onderdelen kunnen op die wijze geen commando's vervalsen. Dit is vergeleken met huidige internet toepassingen slechts een kleinere toepassing.
Als je zou toevoegen: de ene sleutel is meestal publiek bekend gesteld, dan trke ik m'n bezwaar weer in :). [Gebruiker:Panthouse|panthouse]] 23 okt 2003 13:15 (CEST)
Dat is volgens mij nog iets anders, namelijke een hierarchisch systeem, en heeft niet noodzakelijk met asymmetrische encryptie te maken (alhoewel het er wel op gebaseerd kan zijn).