Privacy
- Wat niemand over je mag weten
Encryptie voor leken - en waarom verzwakken onverstandig, en verbieden zinloos is
(A) AANLEIDING
1) De bijdrage van de TS (Topic Starter) in [1] (aardige video trouwens!);
2) De onzinnige gedachte dat we er iets tegen kunnen doen dat terroristen en criminelen onkraakbare encryptie gebruiken (momenteel op de spits gedreven door aanslagen en het, tijd+geldverspillende, FBI-Apple debat);
3) Ik deel graag kennis en ben gevraagd security awareness cursussen te gaan geven (dit dwingt mij om onderwerpen op een rijtje te zetten - ik ontvang natuurlijk graag jullie feedback, ook negatieve!);
4) De veelal lovende reacties op [2];
5) Een soort van visitekaartje i.r.t. hetgeen ik heb opgenomen onder "(O) Ten Slotte".
[1] https://www.security.nl/posting/467761/%5BEncryptie%5D+Should+all+locks+have+keys%3F
[2] https://www.security.nl/posting/405457/SSLv3+%22Poodle%22+lek+voor+leken
(B) INLEIDING EN SCOPE
Algemeen
De secties bovenaan deze bijdrage zijn nogal theoretisch. Sla gerust over wat je niet interessant lijkt. Verderop, vanaf sectie (E), leg ik (aan de hand van een m.i. aardig voorbeeld en zonder ingewikkelde wiskunde) uit hoe encryptie in de basis werkt. Ik hoop dat je in elk geval dat stuk leest, want ik denk dat het zeer verhelderend kan zijn.
Links
In deze bijdrage verwijs ik veelvuldig naar andere sites, veelal Engelstalig (dat laatste omdat artikelen in die taal vaak aanzienlijk beter van kwaliteit zijn dan Nederlandse versies ervan - als die al bestaan). Voor de begripvorming hoef je, is mijn bedoeling, op geen enkele link te klikken. Ik voeg dergelijke links slechts toe voor geïnteresseerden die dieper in de materie wensen te duiken, of door te laten zien wat mijn bron is (en ik dit niet allemaal uit mijn duim zuig).
Ik plaats links steeds onder een "sectie" omdat inline gebruik ervan nogal storend werkt - doordat security.nl clickable links automatisch vet en onderstreept weergeeft, en omdat de links die ik geef vaak lang zijn. Ik gebruik overigens geen URL-shorteners omdat je daarmee niet ziet naar welke site je zult gaan, een gemak dat m.i. nooit opweegt tegen het risico ervan.
Scope
In deze bijdrage ga ik uitsluitend in op symmetrische encryptie, dus niet op asymmetrische encryptie die fundamenteel anders werkt (als lezers in die laatste vorm geïnteresseerd zijn, wil ik daar ook wel eens een bijdrage over proberen te schrijven).
(C) BEGRIPPEN
- encryptie en versleutelen: hier bedoel ik hetzelfde mee;
- decryptie en ontcijferen: idem;
- plaintext [3]: de niet versleutelde informatie (d.w.z. nog niet of niet meer);
- ciphertext [4]: de versleutelde informatie;
- cipher: encryptiealgoritme;
- algoritme: in dit kader, rekenkundige stappen die een (micro-) processor uitvoert om te versleutelen of te ontcijferen;
- contingency: de hoeveelheid "slag om de arm" die je moet houden, rekeninghoudend met (onverwachte) eventualiteiten en/of tegenslagen.
[3] https://en.wikipedia.org/wiki/Plaintext
[4] https://en.wikipedia.org/wiki/Ciphertext
(D) ENCRYPTIE: DOEL, RANDVOORWAARDEN EN PROBLEMEN
Doel
Zorgen dat uitsluitend personen, die jij vertrouwt, de door jou verstrekte informatie kunnen inzien.
Randvoorwaarden
1) Uitsluitend de bedoelde ontvangers (1 of meer) mogen en moeten over de juiste sleutel beschikken om te kunnen decrypten;
2) De ontvanger(s) moeten daarnaast over de juiste software beschikken om te kunnen decrypten;
3) Het moet, in elk geval in de praktijk, onmogelijk zijn om de ciphertext (deels) te kunnen decrypten zonder de sleutel te hebben;
4) Het moet, in elk geval in de praktijk, onmogelijk zijn om de ciphertext zodanig te wijzigen dat A) de ontvanger die manipulatie niet opmerkt en B) de ontvanger de plaintext (als gevolg van de manipulatie van de ciphertext) anders interpreteert dan door jou bedoeld [5].
Met "in de praktijk" bedoel ik dat de waarde van de plaintext, voor al jouw "vijanden" (opponenten) bij elkaar, lager is dan de kosten (ook in de vorm van tijd en gelopen risico's, waaronder vervolging) die in de praktijk door die opponenten gemaakt moeten worden om ofwel de plaintext te kunnen achterhalen, ofwel de ciphertext zodanig kunnen wijzigen dat de ontvanger deze anders interpreteert dan bedoeld door jou. Waarbij er rekening mee gehouden wordt dat jouw opponenten dit kunnen doen op elke door hen gewenste manier (waaronder [6]).
Lastig hierbij is dat je rekening moet houden met de toekomst (contingency); als over een jaar of zo een encryptiealgoritme onverwacht zwakker blijkt te zijn dan eerder aangenomen, of als jij of iemand anders de sleutel niet goed beveiligt, kunnen genoemde kosten aanzienlijk dalen (d.w.z. voor jouw opponenten).
[5] https://en.wikipedia.org/wiki/Malleability_%28cryptography%29
[6] https://xkcd.com/538/ (de CIA- [7] / CDA- [8] aanpak voor toegang krijgen tot onkraakbare encryptie)
[7] http://www.nbcnews.com/news/us-news/director-brennan-cia-won-t-waterboard-again-even-if-ordered-n553756
[8] https://www.security.nl/posting/460719/CDA+wil+decryptiebevel+terug+in+wet+computercriminaliteit
Problemen
1) Het is lastig en vooral tijdrovend om onvoorspelbare en niet te raden encryptiesleutels te bedenken of genereren [9];
2) Zonder elkaar fysiek te onmoeten is het extreem lastig om iemands identiteit met voldoende betrouwbaarheid vast te kunnen stellen (WhatsApp biedt nu end-to-end encryptie, maar wie zit er precies aan de andere kant van de lijn? Denk aan een geleende of gestolen smartphone, of een redirect (doorzetten) van de verbinding naar een ander telefoonnummer bijv. door manipulatie op carrier-niveau [10]) ;
3) Zodra je met voldoende betrouwbaarheid de identiteit van jouw "gesprekspartner(s)" hebt vastgesteld, is het, zonder elkaar fysiek te onmoeten, extreem lastig [11] om op veilige wijze een encryptiesleutel met die "gesprekspartner(s)" te delen;
4) Hooguit jouw verzoek tot geheimhouding kan ontvangers-met-sleutel van jouw versleutelde berichten ervan weerhouden om de plaintext aan anderen dan die jij vertrouwt bekend te maken. Met encryptie los je dit potentiële probleem nooit op.
[9] https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator
[10] https://www.security.nl/posting/468290/GSM+afluisternieuws
[11] https://en.wikipedia.org/wiki/Key_exchange#The_key_exchange_problem
(E) ONKRAAKBARE ENCRYPTIE #1: DE DEAL MET JOUW ZUS
Jouw oudere zusje heeft een vriendje waar zij regelmatig dingen mee doet (dingen waar jij, gezien jouw leeftijd, alleen maar van kan dromen) en daarom regelmatig 's avonds laat thuiskomt - op een moment dat jullie ouders denken dat jullie allebei op jullie zolderkamers in bed liggen (alleen).
Jij krijgt wat geld/snoep van haar als jij haar, stiekem, aangeeft wanneer de kust veilig is om langs de slaapkamer van jullie ouders naar haar zolderkamer te sluipen. Je hebt strenge ouders en daarom heb je nog geen mobieltje (er was een tijd dat niemand zo'n ding had ;-).
Aanvankelijk hadden jullie afgesproken dat jij de lamp boven de trap zou aandoen zodra de kust veilig was. Het vriendje van jouw zus, Willie Wortel genaamd, is een slimme ICT student (sowieso, maar hij heeft ook het vakje booleaanse algebra gevolgd). Hij waarschuwde ervoor dat het zou kunnen gaan opvallen als de lamp boven de trap de volgende ochtend uit is, terwijl jullie ouders deze juist aan hadden gelaten, of andersom. Maar Willie zou Willie niet zijn als hij daar geen raad mee wist...
Willie legde eerst het volgende uit: onderaan maar ook bovenaan de trap naar de 1e verdieping zitten lichtschakelaars - in een zogenaamde hotelschakeling. Met beide schakelaars kun je de lamp zowel aan- als uitdoen. Om precies te zijn vertelde Willie:
- als de bovenkant van een schakelaar is ingedrukt, noem je dit "stand 0"
(bij een gewone, d.w.z. 1 "enkele", schakelaar bijv. in de keuken, zou dit "lamp uit" zijn);
- als de onderkant van een schakelaar is ingedrukt, noem je dit "stand 1"
(bij een gewone, d.w.z. 1 "enkele", schakelaar bijv. in de keuken, zou dit "lamp aan" zijn);
- als beide schakelaars in dezelfde stand staan (beide 0 of beide 1), is de lamp boven de trap uit;
- als de schakelaars in verschillende standen staan (een is 0 en de andere is 1), is de lamp boven de trap aan.
Wat jij (broertje) moet doen, aldus Willie, is:
- Zolang de situatie onveilig is (ouders mogelijk nog wakker zijn), ervoor zorgen dat ofwel de lamp brandt en de schakelaar onderaan de trap op stand 0 staat, ofwel de lamp uit is en de schakelaar onderaan de trap op stand 1 staat. Hier zorg je voor door even te gaan plassen zodra jouw ouders naar bed zijn gegaan (en het licht in de woonkamer uit is); in ongeveer de helft van de gevallen zul je hiervoor de schakelaar bovenaan de trap moet omzetten.
- Zodra de situatie veilig is (beide ouders snurken) zorg je ervoor dat, als de lamp brandt, dat dan de schakelaar onderaan de trap op stand 1 staat, en als de de lamp uit is dat dan de schakelaar onderaan de trap op stand 0 staat (ook hier zul je, in ongeveer de helft van de gevallen, de schakelaar bovenaan de trap moet omzetten).
Wat jouw zus moet doen, aldus Willie, is eerst wachten tot het licht in de woonkamer uit is (de ouders naar bed zijn). Daarna moet zij wachten totdat ofwel de lamp boven de trap brandt en de schakelaar onderaan de trap op stand 1 staat, ofwel de lamp bovenaan de trap uit is en de schakelaar onderaan de trap op stand 0 staat. En alleen dan naar boven sluipen.
Dit is tevens het principe van digitale encryptie. Uitsluitend de observatie van de tegenpartij (hierboven de ouders) dat de lamp aan of uit is, zegt niets. Alleen degene die ook over de sleutel beschikt (hierboven: de stand van de schakelaar beneden, zoals gezien door jouw zus), weet wat de "plaintext" is (de kust is veilig of onveilig).
(F) ONKRAAKBARE ENCRYPTIE #2: DE HOTELSCHAKELING
Voor een betere begripvorming teken ik (met wat moeite op deze site) het elektrische schema van zo'n hotelschakeling:
In de getekende situatie is de lamp uit (er is geen stroomkring mogelijk). Je kunt je hopelijk voorstellen dat het niet uitmaakt welke schakelaar wordt omgezet: de lamp gaat dan aan.
Wat Willie heeft voorgesteld is natuurlijk nodeloos ingewikkeld en er kleven nadelen aan (o.a. kunnen de ouders de schakelaar beneden zien waardoor dat geen geheime sleutel is, als ze de truc niet doorhebben, is dat niet meer dan security by obscurity). Toch wilde ik dit uitgelegd hebben, want verderop hebben we deze basis nodig.
Met jouw zus kun je beter afspreken dat jij, zodra jouw ouders naar bed zijn gegaan maar nog wakker zijn, jij naar beneden gaat, zogenaamd om te plassen, waarna je je ervan verzekert dat het licht in de WC uit is. Zodra de kust veilig is, ga je nogmaals naar beneden en "vergeet" daarbij het licht uit te doen in de WC. Jouw zus weet dan dat de kust veilig is als het licht in de WC brandt.
Echter: zo'n regelmatig brandende lamp zou wel eens kunnen gaan opvallen!
Wat je daarom doet is het volgende:
- elke keer voordat jouw zus weggaat gooi je een muntje op [12];
- bij munt spreek je af dat, als het licht aan is in de WC, dit betekent dat de kust veilig is, en bij kruis dat licht aan in de WC juist onveilig betekent.
Voor een buitenstaander zal het volstrekt onduidelijk zijn wat de relatie is tussen enerzijds licht aan/uit in de WC en anderzijds kust veilig/onveilig; om die relatie te weten, moeten zowel jouw zus als jij de waarde van de sleutel kennen (kruis of munt) - informatie die je natuurlijk niet aan anderen vertelt. Handige bijkomstigheid: door een munt op te gooien heeft die sleutel een onvoorspelbare waarde (ook voor derden).
Concreet is hierbij sprake van een pre-shared key [13] (vooraf gedeelde sleutel), ook bekend als shared secret [14] (gedeeld geheim).
[12] https://nl.wikipedia.org/wiki/Kruis_of_munt
[13] https://en.wikipedia.org/wiki/Pre-shared_key
[14] https://en.wikipedia.org/wiki/Shared_secret
(G) ONKRAAKBARE ENCRYPTIE #3: MEER DAN 1 BIT
In de bovenstaande voorbeelden hebben we het, effectief, steeds over 1 "bit" gehad: 1 schakelaar in de stand 0 of 1 en de uitslag "kruis of munt". Echter, meestal willen we meer informatie versleutelen. Dat kan, in elk geval, met evenveel hotelschakelingen als "bits" die wij willen versleutelen!
Nb. verderop ga ik wat dieper in op wat "bits" zijn, maar wellicht begrijp je dat voldoende om door te kunnen lezen en mijn (lange) verhaal te kunnen blijven volgen.
(H) PRAKTIJKVOORBEELD: VOETBALLERS OMKOPEN
Stel jij hebt een deal met een coach van het voetbalelftal over het omkopen van spelers, maar je wilt pas vlak voor de wedstijd aan die coach kenbaar maken welke spelers moeten worden omgekocht, zodanig dat niemand weet wat jullie uitspoken. Laten we uitgaan van 11 rugnummers (P.S. voetbal laat mij koud).
Vooraf gooi je, samen met die coach, 11x een muntje op. Stel kruis noemen we 1 en munt noemen we 0, en stel dat 11 keer gooien het volgende oplevert 1, 0, 0, 1, 0, 1, 1, 1, 0, 0, 1.
En stel dat jij, vlak voor de wedstrijd, wilt dat rugnummers 3, 6 en 10 worden omgekocht, dus: 0, 0, 1, 0, 0, 1, 0, 0, 0, 1, 0.
Zet dan die twee rijen cijfers onder elkaar en bereken de derde rij:
De berekening hierboven vindt plaats per kolom (zonder dat kolommen daarbij invloed hebben op elkaar; in tegenstelling tot bij bijvoorbeeld optellen is er geen sprake van "onthouden"). Net als bij de hotelschakeling geldt: als het cijfer boven (de 1e regel) geljjk is aan daaronder (de 2e regel) komt er een 0 in de resultaatregel; anders komt er een 1 in de resultaatregel.
Je belt de coach kort voor aanvang van de wedstrijd, en noemt achter elkaar de cijfers 1, 0, 1, 1, 0, 0, 1, 1, 0, 1 en 1. Mocht iemand meeluisteren dan kan hij of zij hier geen touw aan vastknopen; immers hij of zij kent de sleutel niet.
De coach voert exact dezelfde berekening uit - het gaat hier namelijk om symmetrische encryptie (dezeldfe sleutel en hetzelfde algoritme worden gebruikt:
En daarmee weet de coach welke spelers moeten worden omgekocht.
(J) BITS, BYTES EN COMPUTERCODE
Feitelijk hebben we hierboven al gebruik gemaakt van "bits" die de waarde 0 of 1 kunnen aannemen. Zoals je wellicht zult weten, werken computers uitsluitend met bits. Een bit kun je je op allerlei verschillende manieren voorstellen:
- schakelaar aan of schakelaar uit;
- lamp aan of lamp uit;
- 5 Volt of 0 Volt;
- stroom of geen stroom;
- waar of onwaar;
- ja of nee;
- 1 of 0.
enzovoort, wat je maar wilt; het zal de computer een rotzorg zijn wat jij ermee wilt zeggen. Gebruikelijk is te stellen dat een bit de waarde 0 of 1 heeft, net als dat een decimaal cijfer slechts een van de waarden 0, 1, 2, 3, 4, 5, 6, 7, 8 of 9 moet hebben (een andere waarde kan niet).
Conventie (een afspraak dus) is het om groepjes van 8 bits bij elkaar te denken en dat een byte te noemen. Hier bestaat feitelijk geen enkele noodzaak voor, het is gewoon handig. Moderne computers werken trouwens nauwelijks nog met bytes, maar meestal met groepjes van 32 bits (4 bytes) of 64 bits (8 bytes) tegelijk.
Laten we, om ingewikkelde zaken als hexadecimale getallen te vermijden, het gewoon op bits houden. Dus laten we aannemen dat elk bestand N bits lang is. In de praktijk betekent dit dat je de bestandslengte in bytes met 8 moet vermenigvuldigen om de lengte in bits te krijgen; niet echt moeilijk lijkt me. Maar als een bestand 11 bits lang zou kunnen zijn (zie de voetballers), zou de volgende berekening (cipher) gewoon haar werk kunnen doen.
(K) SIMPELE ONKRAAKBARE ENCRYPTIE
In tegenstelling tot wat de lezer waarschijnlijk verwacht is de beste encryptie het simpelst. Deze vorm van encryptie (bekend als one-time pad [16]) kent wel enkele stevige nadelen (naast het feit dat de sleutel volstrekt onvoorspelbaar moet zijn, maar dat geldt ook voor alle andere soorten encryptie):
1) de sleutel moet minstens even lang zijn (in aantallen bits) als de plaintext;
2) je mag nooit en te nimmer (delen van) zo'n sleutel hergebruiken;
3) bij grotere plaintext bestanden kan de noodzakelijke lengte van de sleutel het erg moeilijk maken om die sleutel veilig uit te wisselen (veel lastiger dan bij een wachtwoord zoals "Welkom01").
Hoe dan ook, als dat allemaal geen issue is kun je het volgende programma gebruiken, dat ik in "pseudo code" van een cipher weergeef:
Dit ziet er wellicht ingewikkeld uit voor een leek. Echter, een werkend programma schrijven op basis van de bovenstaande pseudocode, is een peuleschil voor elke programmeur.
In het midden van de "routine" (de bovenstaande pseudocode) herken je waarschijnlijk de hotelschakeling (ter herinnering: met beide schakelaars in dezelfde stand is de lamp aan, anders is deze uit).
Ook hier gaat het om symmetrische encryptie: je kunt dezelfde routine gebruiken, zowel om te versleutelen als om te ontcijferen! Daarmee is deze routine geschikt om bijv. voetballers mee om te kopen en kan zowel door de opdrachtgever als de coach worden gebruikt. Beiden gebruiken dezelfde SleutelFile, echter de opdrachtgever stopt de plaintext in de InputFile, terwijl de coach de ontvangen ciphertext in de InputFile stopt. Met die tweede stap (ontcijferen) berekent het progrmma weer dezelfde plaintext als door de opdrachtgever in "zijn" InputFile gestopte gegevens.
[16] https://en.wikipedia.org/wiki/One-time_pad
(L) ALOM, IN DE PRAKTIJK, GEBRUIKTE ENCRYPTIE
In de praktijk wordt "one-time pad" [16] encryptie zelden gebruikt. De belangrijkste reden daarvoor is dat de sleutel minstens even lang moet zijn als de plaintext, en dat maakt het veilige uitwisselen ervan vaak erg lastig - tenzij je elkaar vooraf kunt ontmoeten om dan, bijvoorbeeld, een stapel papier of een USB-geheugenstick uit te wisselen.
Ik wil in een ander artikel wel eens verder ingaan op stream- en block ciphers), maar in essentie komt het allemaal redelijk op hetzelfde neer: uit een relatief korte sleutel of wachtwoord wordt, kunstmatig, een langere reeks bits gegenereerd [17]. Deze berekening moet voor beide partijen (versleutelaar en ontsleutelaar) natuurlijk exact dezelfde bitreeks opleveren.
Je zult vermoedelijk wel begrijpen dat, hoe korter dat wachtwoord is, hoe minder moeilijk het "raden" daarvan wordt als je dat eindeloos zou kunnen blijven proberen (brute force aanpak). Het "stretchen" van het wachtwoord tot een langere reeks bits heeft hier geen enkele invloed op. Dit nog even los van het feit dat dit soort "wachtwoord-stretchers" in de praktijk vaak zwakheden vertonen (er bijv. repeterende patronen in voorkomen) die de bedenkers zich niet hebben gerealiseerd tijdens het ontwerpen van de cipher (voorbeeld: [18]).
[17] https://en.m.wikipedia.org/wiki/Key_stretching
[18] https://www.rc4nomore.com/
(M) GEBRUIK VAN ENCRYPTIE VOOR ONGEWENSTE PRAKTIJKEN
Hierboven heb ik al laten zien dat je encryptie zou kunnen gebruiken bij het omkopen van voetballers (toegegeven, een niet erg realistisch scenario). De eenvoud van de hierboven beschreven -onkraakbare- encryptie heeft tot gevolg dat ook (cyber-) criminelen, terroristen en ander gespuis, indien zij vooraf samenkomen om sleutels uit te wisselen, zich niets hoeven aan te trekken van welke maatregel dan ook die wij nemen in een poging de door hen gebruikte encryptie te kunnen ontcijferen. Immers, iedereen met een beetje programmeerervaring kan zo'n programma schrijven. Hoewel het genereren van zeer lange, onvoorspelbare, getallen tijd kost, is dit niet moeilijk; desnoods gooi je heel vaak een muntje op. De vraag daarbij is sowieso of terroristen zeer lange sleutels nodig hebben. Immers: gegevens als datum, tijd en plaats passen in een beperkt aantal bytes.
Je houdt dit niet tegen. Mijn oproep aan politici luidt daarom: besteed jouw eigen tijd, en die van bezorgde burgers, aan zinvoller dingen om die gasten te pakken!
(N) CONCLUSIE
HET IS ONVERSTANDIG OM ALOM GEBRUIKTE ENCRYPTIE TE VERZWAKKEN
En:
HET IS ZINLOOS OM (KRACHTIGE) ENCRYPTIE TE VERBIEDEN
Erger:
MET VERZWAKKEN OF VERBIEDEN VAN ENCRYPTIE SCHAAD JE UITSLUITEND EERLIJKE GEBRUIKERS
(O) TEN SLOTTE
Ik zoek een andere baan in midden Nederland (dit is geen hoax of zo). Heeft iemand een idee?
In de hoop op meer tips (met dank aan SecOff 12:51), wat meer details over mijzelf (zonder opmaak om het compact te houden want dit is natuurlijk off-topic op deze site en onder dit artikel). Uitdagend vind ik het, risk driven, vertalen van de (nogal abstracte) controls uit ISO27002 (d.w.z. de annex van ISO27001) of NEN7510 in werkbare maatregelen die voor iedereen (gebruikers, beheerders, management en auditors) een acceptabel compromis vormen; ik heb 2 weken geleden nog een ICT bedrijf begeleid naar haar ISO 27001 certificering. De overheid wil dat ik nog 10 jaar werk (en zelf doe ik dat ook heel graag - zoek verder als je me te oud vindt). M.b.t. cybersecurity weet ik meestal heel goed waar ik het over heb. En als ik eigenwijs blijk te zijn geweest, ben ik altijd bereid om sorry te zeggen - en dat doe ik ook als ik iets concreets verkeerd heb gedaan. Ik ben geen projectleider en ambieer geen leidinggevende functie. En, omdat ik wil kunnen zeggen waar het op staat, ben ik niet zo geschikt voor "politieke omgevingen". Ik wil graag verantwoordelijkheid dragen, maar eis daarbij dan wel een passend mandaat. Daarnaast heb ik veel tijd nodig om bij te blijven op mijn vakgebied; dat doe ik niet uitsluitend in mijn eigen tijd. Het lijkt mij heel leuk om security-awareness cursussen te geven (ook aan SW ontwikkelaars), maar ik heb nog nauwelijks ervaring met het geven van trainingen. Ik ben OS-neutraal: get the best tool for the job. Cloud en BYOD vind ik zeer risicovolle aangelegenheden die meestal tegen beter weten in, of tegenargumenten geheel niet overwogen hebbend, zijn ingevoerd - vaak omdat de baas ze zo handig vond. Zoek dus verder als je niet weet wat de woorden "management commitment" betekenen, maar ook als je niet begrijpt wat die woorden voor jou, als manager, in de praktijk betekenen (vul de PDF eens in waar ik in [19] naar verwijs). Ik ben gek op "forensisch"-achtig onderzoek en (malware) analyses, en ben zeer secuur; zoek verder als je een jaknikkende snelle Henkie wenst. Ik vind geld totaal ondergeschikt aan lol in mijn werk, maar ga niet meer een "kasboek voor privéuitgaven" bijhouden. Ik heb een eigen auto en -gelukkig- een goede gezondheid. Ik heb recentelijk nog een (zware) screening met goed gevolg doorstaan.
[19] https://www.security.nl/posting/467428/Hoe+security+aware+is+jouw+werkgever%3F#posting467543
(P) Wijzigingsregister
Wijzigingen 21-04-2016, 04:45: diverse tekstfouten gecorrigeerd en enkele links tegevoegd.
Wijzigingen 21-04-2016, 08:53: (zich schamend) er zaten nog steeds fouten in de berekeningen van de 11 voetballers.
Wijziging 21-04-2016, 15:23: dit wijzigingsrgeister zelf leek nergens op... (gefixt)
Wijziging 21-04-2016, 16:21: ik heb een stuk over mijzelf toegevoegd onder "(O) TEN SLOTTE".
Opmerking 21-04-2016, 17:28: vanavond t/m maandagavond 25 april ben ik druk met privézaken waardoor ik waarschijnlijk niet in de gelegenheid ben in te gaan op vragen of opmerkingen onder dit artikel.
Wijziging 22-04-2016, 19:07: "*(A)" => "(A)"; taal- en functionele fouten gecorrigeerd n.a.v. -volkomen terechte- opmerkingen van Woopie, vandaag om 17:29 (taalfouten in teksten van anderen leiden mij ook vaak af van het onderwerp, en dat is jammer; dat maakt je echt geen taalnazi). "WS" => "WC" en "waarder" => "zwaarder". Veel belangrijker: er zat een suffe redenatiefout in het schema van de hotelschakeling. Knap gevonden van Woopie, hartelijk dank! Ik heb het met wat moeite kunnen oplossen, gelukkig zonder Alt-255 nodig te hebben (want die heb ik niet op mijn mobiel ;-). Nogmaals dank aan deze oplettende lezer!
Aanvulling 07-05-2016, 02:07: n.a.v. -terechte- opmerkingen van Goeroehoedjes op 06-05-2017 om 17:06: tikfouten gecorrigeerd (OuputFile->OutputFile, Gebuikelijk->Gebruikelijk) en, ter verduidelijking, achter de tekst "Schrijf "OutBit" naar "OutputFile" door de waarde helemaal achteraan te plakken" de toevoeging "(het bestand wordt daarmee 1 bit langer)" erachter gezet.
Aamvulling 10-05-2016, 08:00: enkele taal/spelfoutjes gefixed.
1) De bijdrage van de TS (Topic Starter) in [1] (aardige video trouwens!);
2) De onzinnige gedachte dat we er iets tegen kunnen doen dat terroristen en criminelen onkraakbare encryptie gebruiken (momenteel op de spits gedreven door aanslagen en het, tijd+geldverspillende, FBI-Apple debat);
3) Ik deel graag kennis en ben gevraagd security awareness cursussen te gaan geven (dit dwingt mij om onderwerpen op een rijtje te zetten - ik ontvang natuurlijk graag jullie feedback, ook negatieve!);
4) De veelal lovende reacties op [2];
5) Een soort van visitekaartje i.r.t. hetgeen ik heb opgenomen onder "(O) Ten Slotte".
[1] https://www.security.nl/posting/467761/%5BEncryptie%5D+Should+all+locks+have+keys%3F
[2] https://www.security.nl/posting/405457/SSLv3+%22Poodle%22+lek+voor+leken
(B) INLEIDING EN SCOPE
Algemeen
De secties bovenaan deze bijdrage zijn nogal theoretisch. Sla gerust over wat je niet interessant lijkt. Verderop, vanaf sectie (E), leg ik (aan de hand van een m.i. aardig voorbeeld en zonder ingewikkelde wiskunde) uit hoe encryptie in de basis werkt. Ik hoop dat je in elk geval dat stuk leest, want ik denk dat het zeer verhelderend kan zijn.
Links
In deze bijdrage verwijs ik veelvuldig naar andere sites, veelal Engelstalig (dat laatste omdat artikelen in die taal vaak aanzienlijk beter van kwaliteit zijn dan Nederlandse versies ervan - als die al bestaan). Voor de begripvorming hoef je, is mijn bedoeling, op geen enkele link te klikken. Ik voeg dergelijke links slechts toe voor geïnteresseerden die dieper in de materie wensen te duiken, of door te laten zien wat mijn bron is (en ik dit niet allemaal uit mijn duim zuig).
Ik plaats links steeds onder een "sectie" omdat inline gebruik ervan nogal storend werkt - doordat security.nl clickable links automatisch vet en onderstreept weergeeft, en omdat de links die ik geef vaak lang zijn. Ik gebruik overigens geen URL-shorteners omdat je daarmee niet ziet naar welke site je zult gaan, een gemak dat m.i. nooit opweegt tegen het risico ervan.
Scope
In deze bijdrage ga ik uitsluitend in op symmetrische encryptie, dus niet op asymmetrische encryptie die fundamenteel anders werkt (als lezers in die laatste vorm geïnteresseerd zijn, wil ik daar ook wel eens een bijdrage over proberen te schrijven).
(C) BEGRIPPEN
- encryptie en versleutelen: hier bedoel ik hetzelfde mee;
- decryptie en ontcijferen: idem;
- plaintext [3]: de niet versleutelde informatie (d.w.z. nog niet of niet meer);
- ciphertext [4]: de versleutelde informatie;
- cipher: encryptiealgoritme;
- algoritme: in dit kader, rekenkundige stappen die een (micro-) processor uitvoert om te versleutelen of te ontcijferen;
- contingency: de hoeveelheid "slag om de arm" die je moet houden, rekeninghoudend met (onverwachte) eventualiteiten en/of tegenslagen.
[3] https://en.wikipedia.org/wiki/Plaintext
[4] https://en.wikipedia.org/wiki/Ciphertext
(D) ENCRYPTIE: DOEL, RANDVOORWAARDEN EN PROBLEMEN
Doel
Zorgen dat uitsluitend personen, die jij vertrouwt, de door jou verstrekte informatie kunnen inzien.
Randvoorwaarden
1) Uitsluitend de bedoelde ontvangers (1 of meer) mogen en moeten over de juiste sleutel beschikken om te kunnen decrypten;
2) De ontvanger(s) moeten daarnaast over de juiste software beschikken om te kunnen decrypten;
3) Het moet, in elk geval in de praktijk, onmogelijk zijn om de ciphertext (deels) te kunnen decrypten zonder de sleutel te hebben;
4) Het moet, in elk geval in de praktijk, onmogelijk zijn om de ciphertext zodanig te wijzigen dat A) de ontvanger die manipulatie niet opmerkt en B) de ontvanger de plaintext (als gevolg van de manipulatie van de ciphertext) anders interpreteert dan door jou bedoeld [5].
Met "in de praktijk" bedoel ik dat de waarde van de plaintext, voor al jouw "vijanden" (opponenten) bij elkaar, lager is dan de kosten (ook in de vorm van tijd en gelopen risico's, waaronder vervolging) die in de praktijk door die opponenten gemaakt moeten worden om ofwel de plaintext te kunnen achterhalen, ofwel de ciphertext zodanig kunnen wijzigen dat de ontvanger deze anders interpreteert dan bedoeld door jou. Waarbij er rekening mee gehouden wordt dat jouw opponenten dit kunnen doen op elke door hen gewenste manier (waaronder [6]).
Lastig hierbij is dat je rekening moet houden met de toekomst (contingency); als over een jaar of zo een encryptiealgoritme onverwacht zwakker blijkt te zijn dan eerder aangenomen, of als jij of iemand anders de sleutel niet goed beveiligt, kunnen genoemde kosten aanzienlijk dalen (d.w.z. voor jouw opponenten).
[5] https://en.wikipedia.org/wiki/Malleability_%28cryptography%29
[6] https://xkcd.com/538/ (de CIA- [7] / CDA- [8] aanpak voor toegang krijgen tot onkraakbare encryptie)
[7] http://www.nbcnews.com/news/us-news/director-brennan-cia-won-t-waterboard-again-even-if-ordered-n553756
[8] https://www.security.nl/posting/460719/CDA+wil+decryptiebevel+terug+in+wet+computercriminaliteit
Problemen
1) Het is lastig en vooral tijdrovend om onvoorspelbare en niet te raden encryptiesleutels te bedenken of genereren [9];
2) Zonder elkaar fysiek te onmoeten is het extreem lastig om iemands identiteit met voldoende betrouwbaarheid vast te kunnen stellen (WhatsApp biedt nu end-to-end encryptie, maar wie zit er precies aan de andere kant van de lijn? Denk aan een geleende of gestolen smartphone, of een redirect (doorzetten) van de verbinding naar een ander telefoonnummer bijv. door manipulatie op carrier-niveau [10]) ;
3) Zodra je met voldoende betrouwbaarheid de identiteit van jouw "gesprekspartner(s)" hebt vastgesteld, is het, zonder elkaar fysiek te onmoeten, extreem lastig [11] om op veilige wijze een encryptiesleutel met die "gesprekspartner(s)" te delen;
4) Hooguit jouw verzoek tot geheimhouding kan ontvangers-met-sleutel van jouw versleutelde berichten ervan weerhouden om de plaintext aan anderen dan die jij vertrouwt bekend te maken. Met encryptie los je dit potentiële probleem nooit op.
[9] https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator
[10] https://www.security.nl/posting/468290/GSM+afluisternieuws
[11] https://en.wikipedia.org/wiki/Key_exchange#The_key_exchange_problem
(E) ONKRAAKBARE ENCRYPTIE #1: DE DEAL MET JOUW ZUS
Jouw oudere zusje heeft een vriendje waar zij regelmatig dingen mee doet (dingen waar jij, gezien jouw leeftijd, alleen maar van kan dromen) en daarom regelmatig 's avonds laat thuiskomt - op een moment dat jullie ouders denken dat jullie allebei op jullie zolderkamers in bed liggen (alleen).
Jij krijgt wat geld/snoep van haar als jij haar, stiekem, aangeeft wanneer de kust veilig is om langs de slaapkamer van jullie ouders naar haar zolderkamer te sluipen. Je hebt strenge ouders en daarom heb je nog geen mobieltje (er was een tijd dat niemand zo'n ding had ;-).
Aanvankelijk hadden jullie afgesproken dat jij de lamp boven de trap zou aandoen zodra de kust veilig was. Het vriendje van jouw zus, Willie Wortel genaamd, is een slimme ICT student (sowieso, maar hij heeft ook het vakje booleaanse algebra gevolgd). Hij waarschuwde ervoor dat het zou kunnen gaan opvallen als de lamp boven de trap de volgende ochtend uit is, terwijl jullie ouders deze juist aan hadden gelaten, of andersom. Maar Willie zou Willie niet zijn als hij daar geen raad mee wist...
Willie legde eerst het volgende uit: onderaan maar ook bovenaan de trap naar de 1e verdieping zitten lichtschakelaars - in een zogenaamde hotelschakeling. Met beide schakelaars kun je de lamp zowel aan- als uitdoen. Om precies te zijn vertelde Willie:
- als de bovenkant van een schakelaar is ingedrukt, noem je dit "stand 0"
(bij een gewone, d.w.z. 1 "enkele", schakelaar bijv. in de keuken, zou dit "lamp uit" zijn);
- als de onderkant van een schakelaar is ingedrukt, noem je dit "stand 1"
(bij een gewone, d.w.z. 1 "enkele", schakelaar bijv. in de keuken, zou dit "lamp aan" zijn);
- als beide schakelaars in dezelfde stand staan (beide 0 of beide 1), is de lamp boven de trap uit;
- als de schakelaars in verschillende standen staan (een is 0 en de andere is 1), is de lamp boven de trap aan.
Wat jij (broertje) moet doen, aldus Willie, is:
- Zolang de situatie onveilig is (ouders mogelijk nog wakker zijn), ervoor zorgen dat ofwel de lamp brandt en de schakelaar onderaan de trap op stand 0 staat, ofwel de lamp uit is en de schakelaar onderaan de trap op stand 1 staat. Hier zorg je voor door even te gaan plassen zodra jouw ouders naar bed zijn gegaan (en het licht in de woonkamer uit is); in ongeveer de helft van de gevallen zul je hiervoor de schakelaar bovenaan de trap moet omzetten.
- Zodra de situatie veilig is (beide ouders snurken) zorg je ervoor dat, als de lamp brandt, dat dan de schakelaar onderaan de trap op stand 1 staat, en als de de lamp uit is dat dan de schakelaar onderaan de trap op stand 0 staat (ook hier zul je, in ongeveer de helft van de gevallen, de schakelaar bovenaan de trap moet omzetten).
Wat jouw zus moet doen, aldus Willie, is eerst wachten tot het licht in de woonkamer uit is (de ouders naar bed zijn). Daarna moet zij wachten totdat ofwel de lamp boven de trap brandt en de schakelaar onderaan de trap op stand 1 staat, ofwel de lamp bovenaan de trap uit is en de schakelaar onderaan de trap op stand 0 staat. En alleen dan naar boven sluipen.
Dit is tevens het principe van digitale encryptie. Uitsluitend de observatie van de tegenpartij (hierboven de ouders) dat de lamp aan of uit is, zegt niets. Alleen degene die ook over de sleutel beschikt (hierboven: de stand van de schakelaar beneden, zoals gezien door jouw zus), weet wat de "plaintext" is (de kust is veilig of onveilig).
(F) ONKRAAKBARE ENCRYPTIE #2: DE HOTELSCHAKELING
Voor een betere begripvorming teken ik (met wat moeite op deze site) het elektrische schema van zo'n hotelschakeling:
,----------------------------o ~ 230V (nul)
|
(X) Lamp (boven)
|
o
/ Schakelaar (boven)
o o (in stand 0)
| |
| | (draden weggewerkt in de muur langs de trap)
| |
o o
/ Schakelaar (beneden)
o (in stand 0 - Nb. deze is andersom bedraad!)
|
`----------------------------o ~ 230V (fase)
|
(X) Lamp (boven)
|
o
/ Schakelaar (boven)
o o (in stand 0)
| |
| | (draden weggewerkt in de muur langs de trap)
| |
o o
/ Schakelaar (beneden)
o (in stand 0 - Nb. deze is andersom bedraad!)
|
`----------------------------o ~ 230V (fase)
Let op: de schakelaar beneden is precies andersom bedraad t.o.v. de schakelaar boven.
Terzijde: als je beide schakelaars op exact dezelfde wijze zou willen bedraden, zul je de draden (weggewerkt in de muur langs de trap) moeten kruisen. Helaas lukt het mij niet om gekruiste draden te "tekenen", gebruikmakend van de karakterset en lettertype op deze site (security.nl).
Overigens zal geen enkele elektriciën erop letten of deze draden gekruist zijn of niet. Beide draden zijn zogenaamde schakeldraden en hebben daarom een zwarte isolatiemantel, waardoor je ze -op het oog- niet uit elkaar kunt houden. Ten slotte maakt het gebruikers ook niets uit of de draden gekruist zijn of niet, want uit de stand van een van die schakelaars kun je alleen afleiden dat de lamp moet branden (of juist niet ) als je (1) weet wat de stand van de andere schakelaar is (die je meestal niet kunt zien als je voor een schakelaar staat) en (2) als je weet of die draden gekruist zijn of juist niet.
Terzijde: als je beide schakelaars op exact dezelfde wijze zou willen bedraden, zul je de draden (weggewerkt in de muur langs de trap) moeten kruisen. Helaas lukt het mij niet om gekruiste draden te "tekenen", gebruikmakend van de karakterset en lettertype op deze site (security.nl).
Overigens zal geen enkele elektriciën erop letten of deze draden gekruist zijn of niet. Beide draden zijn zogenaamde schakeldraden en hebben daarom een zwarte isolatiemantel, waardoor je ze -op het oog- niet uit elkaar kunt houden. Ten slotte maakt het gebruikers ook niets uit of de draden gekruist zijn of niet, want uit de stand van een van die schakelaars kun je alleen afleiden dat de lamp moet branden (of juist niet ) als je (1) weet wat de stand van de andere schakelaar is (die je meestal niet kunt zien als je voor een schakelaar staat) en (2) als je weet of die draden gekruist zijn of juist niet.
Wat Willie heeft voorgesteld is natuurlijk nodeloos ingewikkeld en er kleven nadelen aan (o.a. kunnen de ouders de schakelaar beneden zien waardoor dat geen geheime sleutel is, als ze de truc niet doorhebben, is dat niet meer dan security by obscurity). Toch wilde ik dit uitgelegd hebben, want verderop hebben we deze basis nodig.
Met jouw zus kun je beter afspreken dat jij, zodra jouw ouders naar bed zijn gegaan maar nog wakker zijn, jij naar beneden gaat, zogenaamd om te plassen, waarna je je ervan verzekert dat het licht in de WC uit is. Zodra de kust veilig is, ga je nogmaals naar beneden en "vergeet" daarbij het licht uit te doen in de WC. Jouw zus weet dan dat de kust veilig is als het licht in de WC brandt.
Echter: zo'n regelmatig brandende lamp zou wel eens kunnen gaan opvallen!
Wat je daarom doet is het volgende:
- elke keer voordat jouw zus weggaat gooi je een muntje op [12];
- bij munt spreek je af dat, als het licht aan is in de WC, dit betekent dat de kust veilig is, en bij kruis dat licht aan in de WC juist onveilig betekent.
Voor een buitenstaander zal het volstrekt onduidelijk zijn wat de relatie is tussen enerzijds licht aan/uit in de WC en anderzijds kust veilig/onveilig; om die relatie te weten, moeten zowel jouw zus als jij de waarde van de sleutel kennen (kruis of munt) - informatie die je natuurlijk niet aan anderen vertelt. Handige bijkomstigheid: door een munt op te gooien heeft die sleutel een onvoorspelbare waarde (ook voor derden).
Concreet is hierbij sprake van een pre-shared key [13] (vooraf gedeelde sleutel), ook bekend als shared secret [14] (gedeeld geheim).
[12] https://nl.wikipedia.org/wiki/Kruis_of_munt
[13] https://en.wikipedia.org/wiki/Pre-shared_key
[14] https://en.wikipedia.org/wiki/Shared_secret
(G) ONKRAAKBARE ENCRYPTIE #3: MEER DAN 1 BIT
In de bovenstaande voorbeelden hebben we het, effectief, steeds over 1 "bit" gehad: 1 schakelaar in de stand 0 of 1 en de uitslag "kruis of munt". Echter, meestal willen we meer informatie versleutelen. Dat kan, in elk geval, met evenveel hotelschakelingen als "bits" die wij willen versleutelen!
Nb. verderop ga ik wat dieper in op wat "bits" zijn, maar wellicht begrijp je dat voldoende om door te kunnen lezen en mijn (lange) verhaal te kunnen blijven volgen.
(H) PRAKTIJKVOORBEELD: VOETBALLERS OMKOPEN
Stel jij hebt een deal met een coach van het voetbalelftal over het omkopen van spelers, maar je wilt pas vlak voor de wedstijd aan die coach kenbaar maken welke spelers moeten worden omgekocht, zodanig dat niemand weet wat jullie uitspoken. Laten we uitgaan van 11 rugnummers (P.S. voetbal laat mij koud).
Vooraf gooi je, samen met die coach, 11x een muntje op. Stel kruis noemen we 1 en munt noemen we 0, en stel dat 11 keer gooien het volgende oplevert 1, 0, 0, 1, 0, 1, 1, 1, 0, 0, 1.
En stel dat jij, vlak voor de wedstrijd, wilt dat rugnummers 3, 6 en 10 worden omgekocht, dus: 0, 0, 1, 0, 0, 1, 0, 0, 0, 1, 0.
Zet dan die twee rijen cijfers onder elkaar en bereken de derde rij:
1 0 0 1 0 1 1 1 0 0 1 (de pre-shared key)
0 0 1 0 0 1 0 0 0 1 0 (plaintext: indexen van rugnummers van om te kopen spelers)
--------------------- (11 x hotelschakeling tussen 1e en 2e rij)
1 0 1 1 0 0 1 1 0 1 1 (te verzenden ciphertext)
0 0 1 0 0 1 0 0 0 1 0 (plaintext: indexen van rugnummers van om te kopen spelers)
--------------------- (11 x hotelschakeling tussen 1e en 2e rij)
1 0 1 1 0 0 1 1 0 1 1 (te verzenden ciphertext)
De berekening hierboven vindt plaats per kolom (zonder dat kolommen daarbij invloed hebben op elkaar; in tegenstelling tot bij bijvoorbeeld optellen is er geen sprake van "onthouden"). Net als bij de hotelschakeling geldt: als het cijfer boven (de 1e regel) geljjk is aan daaronder (de 2e regel) komt er een 0 in de resultaatregel; anders komt er een 1 in de resultaatregel.
Je belt de coach kort voor aanvang van de wedstrijd, en noemt achter elkaar de cijfers 1, 0, 1, 1, 0, 0, 1, 1, 0, 1 en 1. Mocht iemand meeluisteren dan kan hij of zij hier geen touw aan vastknopen; immers hij of zij kent de sleutel niet.
De coach voert exact dezelfde berekening uit - het gaat hier namelijk om symmetrische encryptie (dezeldfe sleutel en hetzelfde algoritme worden gebruikt:
1 0 0 1 0 1 1 1 0 0 1 (de pre-shared key)
1 0 1 1 0 0 1 1 0 1 1 (de ontvangen ciphertext)
--------------------- (11 x hotelschakeling tussen 1e en 2e rij)
0 0 1 0 0 1 0 0 0 1 0 (plaintext: indexen van rugnummers van om te kopen spelers)
1 0 1 1 0 0 1 1 0 1 1 (de ontvangen ciphertext)
--------------------- (11 x hotelschakeling tussen 1e en 2e rij)
0 0 1 0 0 1 0 0 0 1 0 (plaintext: indexen van rugnummers van om te kopen spelers)
Tussendoortje: (I) FBI VERSUS APPLE, NSA VERSUS JUNIPER ETC.
Wat de FBI van Apple vraagt is:
- ofwel: zorg dat jullie te allen tijde weten of het kruis of munt was, en vertel ons dat zodra wij daarom vragen;
- ofwel: maak het muntje aan een kant zwaarder zodat het veel vaker kruis -of juist munt- wordt;
- ofwel: (gokje van mij): doe voor de zekerheid maar allebei.
Juniper had, op verzoek van de NSA, de munt aan een kant zwaarder gemaakt. Vervolgens is Juniper gehacked en is de bijbehorende code door een onbekende aangepast, zodanig dat de andere kant van de munt zwaarder werd. Uiteindelijk heeft Juniper besloten dat het, achteraf bezien, toch niet zo'n goed idee was om (op verzoek van geheime diensten of anderzins) met muntjes te rommelen [15].
[15] https://www.security.nl/posting/457183/Juniper+gaat+NSA-algoritme+uit+ScreenOS+verwijderen
Wat de FBI van Apple vraagt is:
- ofwel: zorg dat jullie te allen tijde weten of het kruis of munt was, en vertel ons dat zodra wij daarom vragen;
- ofwel: maak het muntje aan een kant zwaarder zodat het veel vaker kruis -of juist munt- wordt;
- ofwel: (gokje van mij): doe voor de zekerheid maar allebei.
Juniper had, op verzoek van de NSA, de munt aan een kant zwaarder gemaakt. Vervolgens is Juniper gehacked en is de bijbehorende code door een onbekende aangepast, zodanig dat de andere kant van de munt zwaarder werd. Uiteindelijk heeft Juniper besloten dat het, achteraf bezien, toch niet zo'n goed idee was om (op verzoek van geheime diensten of anderzins) met muntjes te rommelen [15].
[15] https://www.security.nl/posting/457183/Juniper+gaat+NSA-algoritme+uit+ScreenOS+verwijderen
(J) BITS, BYTES EN COMPUTERCODE
Feitelijk hebben we hierboven al gebruik gemaakt van "bits" die de waarde 0 of 1 kunnen aannemen. Zoals je wellicht zult weten, werken computers uitsluitend met bits. Een bit kun je je op allerlei verschillende manieren voorstellen:
- schakelaar aan of schakelaar uit;
- lamp aan of lamp uit;
- 5 Volt of 0 Volt;
- stroom of geen stroom;
- waar of onwaar;
- ja of nee;
- 1 of 0.
enzovoort, wat je maar wilt; het zal de computer een rotzorg zijn wat jij ermee wilt zeggen. Gebruikelijk is te stellen dat een bit de waarde 0 of 1 heeft, net als dat een decimaal cijfer slechts een van de waarden 0, 1, 2, 3, 4, 5, 6, 7, 8 of 9 moet hebben (een andere waarde kan niet).
Conventie (een afspraak dus) is het om groepjes van 8 bits bij elkaar te denken en dat een byte te noemen. Hier bestaat feitelijk geen enkele noodzaak voor, het is gewoon handig. Moderne computers werken trouwens nauwelijks nog met bytes, maar meestal met groepjes van 32 bits (4 bytes) of 64 bits (8 bytes) tegelijk.
Laten we, om ingewikkelde zaken als hexadecimale getallen te vermijden, het gewoon op bits houden. Dus laten we aannemen dat elk bestand N bits lang is. In de praktijk betekent dit dat je de bestandslengte in bytes met 8 moet vermenigvuldigen om de lengte in bits te krijgen; niet echt moeilijk lijkt me. Maar als een bestand 11 bits lang zou kunnen zijn (zie de voetballers), zou de volgende berekening (cipher) gewoon haar werk kunnen doen.
(K) SIMPELE ONKRAAKBARE ENCRYPTIE
In tegenstelling tot wat de lezer waarschijnlijk verwacht is de beste encryptie het simpelst. Deze vorm van encryptie (bekend als one-time pad [16]) kent wel enkele stevige nadelen (naast het feit dat de sleutel volstrekt onvoorspelbaar moet zijn, maar dat geldt ook voor alle andere soorten encryptie):
1) de sleutel moet minstens even lang zijn (in aantallen bits) als de plaintext;
2) je mag nooit en te nimmer (delen van) zo'n sleutel hergebruiken;
3) bij grotere plaintext bestanden kan de noodzakelijke lengte van de sleutel het erg moeilijk maken om die sleutel veilig uit te wisselen (veel lastiger dan bij een wachtwoord zoals "Welkom01").
Hoe dan ook, als dat allemaal geen issue is kun je het volgende programma gebruiken, dat ik in "pseudo code" van een cipher weergeef:
Open "SleutelFile" om eruit te kunnen lezen;
Open "InputFile" om eruit te kunnen lezen;
Open "OutputFile" om naar te schrijven (maak leeg bestand als deze nog niet bestaat);
Geef de variabele genaamd "BitNummer" de waarde 0;
Zolang "BitNummer" < Lengte van "InputFile", herhaal opdrachten tussen accolades:
{
Lees het eerstvolgende bit (1 bit dus) uit "InputFile";
Kopieer de waarde daarvan naar de variabele genaamd "InBit";
Lees het eerstvolgende bit (1 bit dus) uit "SleutelFile";
Kopieer de waarde daarvan naar de variabele genaamd "SleutelBit";
ALS (zowel "InBit" als SleutelBit de waarde 0 hebben)
OF ALS (zowel "InBit" als SleutelBit de waarde 1 hebben)
geef "OutBit" de waarde 0;
Anders:
geef "OutBit" de waarde 1;
Schrijf "OutBit" naar "OutputFile" door de waarde helemaal achteraan te plakken (het bestand wordt daarmee 1 bit langer);
Bereken "BitNummer" + 1 en zet resultaat in "BitNummer";
}
Sluit alle files.
Open "InputFile" om eruit te kunnen lezen;
Open "OutputFile" om naar te schrijven (maak leeg bestand als deze nog niet bestaat);
Geef de variabele genaamd "BitNummer" de waarde 0;
Zolang "BitNummer" < Lengte van "InputFile", herhaal opdrachten tussen accolades:
{
Lees het eerstvolgende bit (1 bit dus) uit "InputFile";
Kopieer de waarde daarvan naar de variabele genaamd "InBit";
Lees het eerstvolgende bit (1 bit dus) uit "SleutelFile";
Kopieer de waarde daarvan naar de variabele genaamd "SleutelBit";
ALS (zowel "InBit" als SleutelBit de waarde 0 hebben)
OF ALS (zowel "InBit" als SleutelBit de waarde 1 hebben)
geef "OutBit" de waarde 0;
Anders:
geef "OutBit" de waarde 1;
Schrijf "OutBit" naar "OutputFile" door de waarde helemaal achteraan te plakken (het bestand wordt daarmee 1 bit langer);
Bereken "BitNummer" + 1 en zet resultaat in "BitNummer";
}
Sluit alle files.
In het midden van de "routine" (de bovenstaande pseudocode) herken je waarschijnlijk de hotelschakeling (ter herinnering: met beide schakelaars in dezelfde stand is de lamp aan, anders is deze uit).
Ook hier gaat het om symmetrische encryptie: je kunt dezelfde routine gebruiken, zowel om te versleutelen als om te ontcijferen! Daarmee is deze routine geschikt om bijv. voetballers mee om te kopen en kan zowel door de opdrachtgever als de coach worden gebruikt. Beiden gebruiken dezelfde SleutelFile, echter de opdrachtgever stopt de plaintext in de InputFile, terwijl de coach de ontvangen ciphertext in de InputFile stopt. Met die tweede stap (ontcijferen) berekent het progrmma weer dezelfde plaintext als door de opdrachtgever in "zijn" InputFile gestopte gegevens.
[16] https://en.wikipedia.org/wiki/One-time_pad
(L) ALOM, IN DE PRAKTIJK, GEBRUIKTE ENCRYPTIE
In de praktijk wordt "one-time pad" [16] encryptie zelden gebruikt. De belangrijkste reden daarvoor is dat de sleutel minstens even lang moet zijn als de plaintext, en dat maakt het veilige uitwisselen ervan vaak erg lastig - tenzij je elkaar vooraf kunt ontmoeten om dan, bijvoorbeeld, een stapel papier of een USB-geheugenstick uit te wisselen.
Ik wil in een ander artikel wel eens verder ingaan op stream- en block ciphers), maar in essentie komt het allemaal redelijk op hetzelfde neer: uit een relatief korte sleutel of wachtwoord wordt, kunstmatig, een langere reeks bits gegenereerd [17]. Deze berekening moet voor beide partijen (versleutelaar en ontsleutelaar) natuurlijk exact dezelfde bitreeks opleveren.
Je zult vermoedelijk wel begrijpen dat, hoe korter dat wachtwoord is, hoe minder moeilijk het "raden" daarvan wordt als je dat eindeloos zou kunnen blijven proberen (brute force aanpak). Het "stretchen" van het wachtwoord tot een langere reeks bits heeft hier geen enkele invloed op. Dit nog even los van het feit dat dit soort "wachtwoord-stretchers" in de praktijk vaak zwakheden vertonen (er bijv. repeterende patronen in voorkomen) die de bedenkers zich niet hebben gerealiseerd tijdens het ontwerpen van de cipher (voorbeeld: [18]).
[17] https://en.m.wikipedia.org/wiki/Key_stretching
[18] https://www.rc4nomore.com/
(M) GEBRUIK VAN ENCRYPTIE VOOR ONGEWENSTE PRAKTIJKEN
Hierboven heb ik al laten zien dat je encryptie zou kunnen gebruiken bij het omkopen van voetballers (toegegeven, een niet erg realistisch scenario). De eenvoud van de hierboven beschreven -onkraakbare- encryptie heeft tot gevolg dat ook (cyber-) criminelen, terroristen en ander gespuis, indien zij vooraf samenkomen om sleutels uit te wisselen, zich niets hoeven aan te trekken van welke maatregel dan ook die wij nemen in een poging de door hen gebruikte encryptie te kunnen ontcijferen. Immers, iedereen met een beetje programmeerervaring kan zo'n programma schrijven. Hoewel het genereren van zeer lange, onvoorspelbare, getallen tijd kost, is dit niet moeilijk; desnoods gooi je heel vaak een muntje op. De vraag daarbij is sowieso of terroristen zeer lange sleutels nodig hebben. Immers: gegevens als datum, tijd en plaats passen in een beperkt aantal bytes.
Je houdt dit niet tegen. Mijn oproep aan politici luidt daarom: besteed jouw eigen tijd, en die van bezorgde burgers, aan zinvoller dingen om die gasten te pakken!
(N) CONCLUSIE
HET IS ONVERSTANDIG OM ALOM GEBRUIKTE ENCRYPTIE TE VERZWAKKEN
En:
HET IS ZINLOOS OM (KRACHTIGE) ENCRYPTIE TE VERBIEDEN
Erger:
MET VERZWAKKEN OF VERBIEDEN VAN ENCRYPTIE SCHAAD JE UITSLUITEND EERLIJKE GEBRUIKERS
(O) TEN SLOTTE
Ik zoek een andere baan in midden Nederland (dit is geen hoax of zo). Heeft iemand een idee?
In de hoop op meer tips (met dank aan SecOff 12:51), wat meer details over mijzelf (zonder opmaak om het compact te houden want dit is natuurlijk off-topic op deze site en onder dit artikel). Uitdagend vind ik het, risk driven, vertalen van de (nogal abstracte) controls uit ISO27002 (d.w.z. de annex van ISO27001) of NEN7510 in werkbare maatregelen die voor iedereen (gebruikers, beheerders, management en auditors) een acceptabel compromis vormen; ik heb 2 weken geleden nog een ICT bedrijf begeleid naar haar ISO 27001 certificering. De overheid wil dat ik nog 10 jaar werk (en zelf doe ik dat ook heel graag - zoek verder als je me te oud vindt). M.b.t. cybersecurity weet ik meestal heel goed waar ik het over heb. En als ik eigenwijs blijk te zijn geweest, ben ik altijd bereid om sorry te zeggen - en dat doe ik ook als ik iets concreets verkeerd heb gedaan. Ik ben geen projectleider en ambieer geen leidinggevende functie. En, omdat ik wil kunnen zeggen waar het op staat, ben ik niet zo geschikt voor "politieke omgevingen". Ik wil graag verantwoordelijkheid dragen, maar eis daarbij dan wel een passend mandaat. Daarnaast heb ik veel tijd nodig om bij te blijven op mijn vakgebied; dat doe ik niet uitsluitend in mijn eigen tijd. Het lijkt mij heel leuk om security-awareness cursussen te geven (ook aan SW ontwikkelaars), maar ik heb nog nauwelijks ervaring met het geven van trainingen. Ik ben OS-neutraal: get the best tool for the job. Cloud en BYOD vind ik zeer risicovolle aangelegenheden die meestal tegen beter weten in, of tegenargumenten geheel niet overwogen hebbend, zijn ingevoerd - vaak omdat de baas ze zo handig vond. Zoek dus verder als je niet weet wat de woorden "management commitment" betekenen, maar ook als je niet begrijpt wat die woorden voor jou, als manager, in de praktijk betekenen (vul de PDF eens in waar ik in [19] naar verwijs). Ik ben gek op "forensisch"-achtig onderzoek en (malware) analyses, en ben zeer secuur; zoek verder als je een jaknikkende snelle Henkie wenst. Ik vind geld totaal ondergeschikt aan lol in mijn werk, maar ga niet meer een "kasboek voor privéuitgaven" bijhouden. Ik heb een eigen auto en -gelukkig- een goede gezondheid. Ik heb recentelijk nog een (zware) screening met goed gevolg doorstaan.
[19] https://www.security.nl/posting/467428/Hoe+security+aware+is+jouw+werkgever%3F#posting467543
(P) Wijzigingsregister
Wijzigingen 21-04-2016, 04:45: diverse tekstfouten gecorrigeerd en enkele links tegevoegd.
Wijzigingen 21-04-2016, 08:53: (zich schamend) er zaten nog steeds fouten in de berekeningen van de 11 voetballers.
Wijziging 21-04-2016, 15:23: dit wijzigingsrgeister zelf leek nergens op... (gefixt)
Wijziging 21-04-2016, 16:21: ik heb een stuk over mijzelf toegevoegd onder "(O) TEN SLOTTE".
Opmerking 21-04-2016, 17:28: vanavond t/m maandagavond 25 april ben ik druk met privézaken waardoor ik waarschijnlijk niet in de gelegenheid ben in te gaan op vragen of opmerkingen onder dit artikel.
Wijziging 22-04-2016, 19:07: "*(A)" => "(A)"; taal- en functionele fouten gecorrigeerd n.a.v. -volkomen terechte- opmerkingen van Woopie, vandaag om 17:29 (taalfouten in teksten van anderen leiden mij ook vaak af van het onderwerp, en dat is jammer; dat maakt je echt geen taalnazi). "WS" => "WC" en "waarder" => "zwaarder". Veel belangrijker: er zat een suffe redenatiefout in het schema van de hotelschakeling. Knap gevonden van Woopie, hartelijk dank! Ik heb het met wat moeite kunnen oplossen, gelukkig zonder Alt-255 nodig te hebben (want die heb ik niet op mijn mobiel ;-). Nogmaals dank aan deze oplettende lezer!
Aanvulling 07-05-2016, 02:07: n.a.v. -terechte- opmerkingen van Goeroehoedjes op 06-05-2017 om 17:06: tikfouten gecorrigeerd (OuputFile->OutputFile, Gebuikelijk->Gebruikelijk) en, ter verduidelijking, achter de tekst "Schrijf "OutBit" naar "OutputFile" door de waarde helemaal achteraan te plakken" de toevoeging "(het bestand wordt daarmee 1 bit langer)" erachter gezet.
Aamvulling 10-05-2016, 08:00: enkele taal/spelfoutjes gefixed.
Reacties (26)
Fantastische post! bookmarked
Nu heb ik zin om je one Time pad te programmeren in C# :)
Thanks
Nu heb ik zin om je one Time pad te programmeren in C# :)
Thanks
21-04-2016, 12:51 door
SecOff
Door Erik van Straten:Ik zoek een andere baan in midden Nederland (dit is geen hoax of zo). Heeft iemand een idee?
http://www.werkenbijavl.nl/vacatures/vacature-medewerker-informatiebeveiliging/
21-04-2016, 15:22 door
Erik van Straten
20-04-2016, 23:22:door Anoniem:Nu heb ik zin om je one Time pad te programmeren in C# :)
Thanks! Ik vond het leuk en uitdagend om dit artikel te schrijven, zonder daarbij de lezer met woorden als "XOR" de stuipen op het lijf te jagen. Maar nu jij wilt gaan programmeren kan ik dat niet meer laten ;-)In semi-pseudo-code (met regelnummers):
1) Open Files // bij problemen: geef foutmelding en stop
2) while !(EndOfFile(InPutFile)) {
3) if (EndOfFile(SleutelFile) || Schijf(vol)) Geef Foutmelding En Stop;
4) SchrijfByte(LeesByte(InputFile) ^ LeesByte(SleutelFile));
5) }
6) Sluit Files // bij problemen: geef foutmelding
2) while !(EndOfFile(InPutFile)) {
3) if (EndOfFile(SleutelFile) || Schijf(vol)) Geef Foutmelding En Stop;
4) SchrijfByte(LeesByte(InputFile) ^ LeesByte(SleutelFile));
5) }
6) Sluit Files // bij problemen: geef foutmelding
Die XOR (^) functie heeft 2 parameters. In bovenstaand voorbeeld, ervan uitgaande dat de pseudo-code functie LeesByte() elke keer 1 byte uit de file leest en retourneert, leiden dus 2 input bytes elke keer tot exact 1 output byte.
Van die 2 "input bytes" worden alle bits (d.w.z. op dezelfde positie in beide bytes) tegelijkertijd met elkaar ge-XOR-ed, als volgt (Ibn staat Input bit n, Sbn staat voor Sleutel bit n en Obn staat voor Output bit n):
Resultaat van LeesByte(InputFile): Ib7 Ib6 Ib5 Ib4 Ib3 Ib2 Ib1 Ib0
| | | | | | | |
XOR XOR XOR XOR XOR XOR XOR XOR
| | | | | | | |
Resultaat van LeesByte(SleutelFile): Sb7 Sb6 Sb5 Sb4 Sb3 Sb2 Sb1 Sb0
------------------------------- Resultaat
Input voor SchrijfByte(OutputFile): Ob7 Ob6 Ob5 Ob4 Ob3 Ob2 Ob1 Ob0
| | | | | | | |
XOR XOR XOR XOR XOR XOR XOR XOR
| | | | | | | |
Resultaat van LeesByte(SleutelFile): Sb7 Sb6 Sb5 Sb4 Sb3 Sb2 Sb1 Sb0
------------------------------- Resultaat
Input voor SchrijfByte(OutputFile): Ob7 Ob6 Ob5 Ob4 Ob3 Ob2 Ob1 Ob0
Die functie kent, voor elke bit (uit de 2 bytes die per keer worden gelezen uit resp. InputFile en Sleutelfile) dezelfde waarheidstabel als een hotelschakeling:
Ibn Sbn Obn
0 0 0
0 1 1
1 0 1
1 1 0
0 0 0
0 1 1
1 0 1
1 1 0
Terzijde: om het programma nog iets sneller te maken (dat zou wel eens verwaarloosbaar kunnen zijn bij moderne processoren) zou je iets als volgt kunnen doen (64 bits i.p.v. 8 bits tegelijk verwerken):
Schrijf8Bytes(Lees8Bytes(InputFile) ^ Lees8Bytes(SleutelFile));
maar bij files die niet een veelvoud van 8 bytes lang zijn, gaat dit natuurlijk fout. En dus zal je programma ingewikkelder moeten worden om ook de laatste paar bytes (max. 7) correct te verwerken en bijtijds te waarschuwen indien EndOfFile dreigt. Hoe je dat moet doen mag je zelf uitzoeken ;-)
Schrijf8Bytes(Lees8Bytes(InputFile) ^ Lees8Bytes(SleutelFile));
maar bij files die niet een veelvoud van 8 bytes lang zijn, gaat dit natuurlijk fout. En dus zal je programma ingewikkelder moeten worden om ook de laatste paar bytes (max. 7) correct te verwerken en bijtijds te waarschuwen indien EndOfFile dreigt. Hoe je dat moet doen mag je zelf uitzoeken ;-)
Door SecOff:
Thanks! Die baan lijkt mij, op zich, hartstikke interessant en eervol, maar de reisafstand (ik woon een stukje ten oosten van Utrecht en ik haat files als ik daar elke dag in moet staan; klanten bezoeken vind ik echter acceptabel) en het maximale inkomen staan me wat tegen. Toch hou ik deze zeker nog even in beraad! Nogmaals dank :-)Door Erik van Straten:Ik zoek een andere baan in midden Nederland (dit is geen hoax of zo). Heeft iemand een idee?
http://www.werkenbijavl.nl/vacatures/vacature-medewerker-informatiebeveiliging/Goed artikel. Ik zou hier graag als toevoeging een tipje van de sluier willen oplichten over de werkelijk gebruikte cryptografie, en nog wat extra punten waarom de sentimenten om een uitzonderingstoegang met een gerechtelijk bevel te maken weliswaar begrijpelijk zijn, maar wiskundig niet opgaan en meer kwaad dan goed zullen doen.
Ik zal, om het wat eenvoudiger te houden, me beperken tot de meest kenmerkende principes. Daarbij laat ik dingen weg, maar hopelijk blijft de kern herkenbaar en begrijpelijk.
Als voorbeeld gebruik ik TLS (https://nl.wikipedia.org/wiki/Transport_Layer_Security). TLS is de motor achter het bekende slotje op de websites. Laten we het komende EK voetbal als voorbeeld nemen. Je bent optimistisch over de kansen van Oranje en bestelt alvast kaarten voor de finale. Je komt op een website en er zit een slotje om je betaling te beveiligen.
Daarachter zit een systeem van digitale handtekeningen (https://en.wikipedia.org/wiki/Digital_signature) en encryptie met een Symmetrische versleuteling (https://en.wikipedia.org/wiki/Symmetric-key_algorithm) en Asymmetrische versleuteling (https://en.wikipedia.org/wiki/Public-key_cryptography), en ook nog andere maatregelen, bijvoorbeeld tegen het herhalen van het bericht. Ik beperk me hier tot de Asymmetrische versleuteling, omdat je je in theorie desnoods met deze versleuteling alleen zou kunnen behelpen. De belangrijkste reden voor de digitale handtekening en de symmetrische versleuteling is dat de performance stukken beter is en er minder data over de lijn gaat. De belangrijkste algemene punten gaan trouwens voor alle vormen op.
Het meest gebruikte Asymmetrische algorithme in TLS is RSA. Wat hier goed is om te onthouden is dat de wiskunde openbaar is, en bovendien niet uitzonderlijk ingewikkeld. Zie als voorbeeld http://mathaware.org/mam/06/Kaliski.pdf. Enigszins vereenvoudigd komt het neer op het wiskundige principe dat machtsverheffing gemakkelijk is uit te rekenen, maar worteltrekken moeilijk. Probeer maar eens op papier de wortel van 18 te berekenen. 16 Gaat wel, uit het hoofd is dat 4. Maar je zal al snel naar een zakrekenmachine grijpen om te weten te komen dat de wortel van 18 4,242640687119285 is. Op dezelfde manier zijn de sleutelparen in RSA tegenwoordig gewoonlijk van een lengte die zich als getal grofweg in een getal van 410 cijfers laat uitdrukken. De <getal van 410 cijfers>e machtswortel uitrekenen is zelfs voor supercomputers te veel gevraagd. Echter, de sleutels heffen elkaar wiskundig op, waardoor als een bericht met de ene sleutel is versleuteld het kinderspel is het met de andere sleutel weer open te krijgen.
Ook met die wetenschap kom je echter niet verder. De veiligheid van het sleutelpaar is enigszins vereenvoudigd gebaseerd op het product tussen twee zeer lange priemgetallen, en door een serie bewerkingen krijg zitten geen van beide priemgetallen in de sleutels. Om, zelfs in het bezit van een van de sleutels, de andere te achterhalen, moet je het product ontbinden in de afzonderlijke priemgetallen. Zelfs voor een supercomputer is dat te veel gevraagd. Het is gewoon te duur en dan nog duurt het te lang om de moeite waard te zijn.
Maar omdat de principes zo eenvoudig zijn, is het dus onmogelijk om sterke cryptografie uit te bannen. Met de vele artikelen in de hand kan iedere redelijk bekwame programmeur zijn eigen RSA oplossing maken. Zelfs al zou je het voor elkaar krijgen om alle kopieën van de artikelen te vernietigen, dan nog kan iedere redelijk bekwame wiskundige met de wetenschap dat het kan op eigen houtje de principes herontdekken. Een organisatie als IS heeft dus aan een wiskundige en een bekwame programmeur genoeg om zijn eigen RSA te maken. Er is ook niets dat de cryptografische wereld daar tegen kan doen. Wiskundige wetten zijn per definitie voor iedereen gelijk.
Een tweede punt is dat veel van de retoriek er op gebaseerd is dat je cryptografie kan hebben die en kraakbaar voor opsporingsdiensten (en dan alleen nog met een gerechtelijk bevel in de hand) en onkraakbaar voor de rest kan zijn. Om dezelfde wiskundige reden is dit niet mogelijk. Iedereen die de wiskunde voldoende begrijpt kan achterhalen hoe een dergelijk algorithme werkt en voor eigen doel van dezelfde kwetsbaarheid gebruik maken.
Een alternatief zou zijn om, net zoals met de TSA approved locks is gebeurd, een database aan te leggen met kopieën van alle sleutels, althans voor zover de mensen zich aan deze ingevoerde verplichting houden om een kopie af te staan. Echter, het fenomeen van de genoemde sloten geeft meteen al een precedent nu de master sleutel printklaar op het internet staat - en de TSA in een reactie die als toonbeeld van bureaucratische onverschilligheid kan dienen al heeft aangegeven dat dit wat hun betreft geen probleem is omdat zij er nog steeds in kunnen (dat criminelen dat dus nu ook kunnen, daar kijken ze niet eens naar). Bovendien wordt een database met deze sleutels (denk onder anderen aan het hele digitale betalingsverkeer) meteen doelwit nummer 1.
Laten we weer terug gaan naar ons voorbeeld van de kaartjes voor de finale. Het sleutelpaar op de website heeft twee functies. Om te beginnen, als jij met de publieke sleutel een bericht versleutelt, kan iedereen het bericht verstuurd hebben, maar alleen de website kan het met de privesleutel lezen. Omgekeerd, als de website met de privesleutel een bericht versleutelt, kan iedereen het lezen, maar alleen de website kan het verstuurd hebben. Het ene ligt aan de grondslag van de versleuteling, het andere aan de digitale handtekening.
Beide principes vallen om op het moment dat de privesleutel niet meer prive is. Jij kan er niet van op aan dat het bericht (met daarin je creditcard nummer en eventuele andere toch wel kritische gegevens) niet onderweg door bijvoorbeeld IS (waarvan intussen bekend is dat ze creditcardfraude als financieringsbron gebruiken) gelezen wordt, en je kan er niet van op aan dat je wel met de organisator aan het praten bent en niet (ook) met IS, en dus daar je creditcardnummer aan geeft in plaats van aan de organisatoren.
Een ander voorbeeld. Een aantal PVV-ers hebben recent bezoek van de politie gehad vanwege kritische uitlatingen over het vluchtelingenbeleid. Even los van of je het eens of oneens bent met het beleid en hun reactie, het laat zien dat de dreiging van politiek getinte inmenging door opsporingsdiensten ook in Nederland nooit ver weg is. Je kan je kritiek versleutelen (en de andere partij laten signen zodat je weet dat je met deze praat), maar in geval van een database met sleutels encryptie is het zelfs niet nodig dat de sleutels uitlekt om dit scenario reëel te maken. En dit is niet op de PVV gericht, alle politieke hoofdstromingen zijn in hun begintijd een als staatsgevaarlijk vervolgde minderheid geweest en de meeste opvattingen die we als vanzelfsprekend beschouwen (zoals vrouwen- en homorechten, zorg voor het milieu, euthanasie en abortus) zijn ooit strafbaar geweest. Sommige zijn nog zowel strafbaar als salonfähig tegelijk (denk bijvoorbeeld aan euthanasie en softdrugs).
Conclusies zijn dus:
1. Het is niet mogelijk om criminelen uit te sluiten van onkraakbare encryptie, omdat volgens de wetten van de wiskunde dit nu eenmaal kan bestaan.
2. De wetten van de wiskunde sluiten uit dat je encryptie kan hebben die tegelijk zowel kraakbaar als onkraakbaar is.
3. Het hebben van een geheime opslagplaats van sleutels is een systeem dat even breekbaar is als een kristallen wijnkaraf. Het geringste scheurtje doet het in duizend scherven uiteenspatten.
4. Het hele maatschappelijke en economische verkeer, inclusief het betalingsverkeer, is voor zover dat online is afhankelijk van onkraakbare encryptie. Tornen aan dit principe neemt de terroristen het werk uit handen om de maatschappij en economie te ontwrichten.
Ik zal, om het wat eenvoudiger te houden, me beperken tot de meest kenmerkende principes. Daarbij laat ik dingen weg, maar hopelijk blijft de kern herkenbaar en begrijpelijk.
Als voorbeeld gebruik ik TLS (https://nl.wikipedia.org/wiki/Transport_Layer_Security). TLS is de motor achter het bekende slotje op de websites. Laten we het komende EK voetbal als voorbeeld nemen. Je bent optimistisch over de kansen van Oranje en bestelt alvast kaarten voor de finale. Je komt op een website en er zit een slotje om je betaling te beveiligen.
Daarachter zit een systeem van digitale handtekeningen (https://en.wikipedia.org/wiki/Digital_signature) en encryptie met een Symmetrische versleuteling (https://en.wikipedia.org/wiki/Symmetric-key_algorithm) en Asymmetrische versleuteling (https://en.wikipedia.org/wiki/Public-key_cryptography), en ook nog andere maatregelen, bijvoorbeeld tegen het herhalen van het bericht. Ik beperk me hier tot de Asymmetrische versleuteling, omdat je je in theorie desnoods met deze versleuteling alleen zou kunnen behelpen. De belangrijkste reden voor de digitale handtekening en de symmetrische versleuteling is dat de performance stukken beter is en er minder data over de lijn gaat. De belangrijkste algemene punten gaan trouwens voor alle vormen op.
Het meest gebruikte Asymmetrische algorithme in TLS is RSA. Wat hier goed is om te onthouden is dat de wiskunde openbaar is, en bovendien niet uitzonderlijk ingewikkeld. Zie als voorbeeld http://mathaware.org/mam/06/Kaliski.pdf. Enigszins vereenvoudigd komt het neer op het wiskundige principe dat machtsverheffing gemakkelijk is uit te rekenen, maar worteltrekken moeilijk. Probeer maar eens op papier de wortel van 18 te berekenen. 16 Gaat wel, uit het hoofd is dat 4. Maar je zal al snel naar een zakrekenmachine grijpen om te weten te komen dat de wortel van 18 4,242640687119285 is. Op dezelfde manier zijn de sleutelparen in RSA tegenwoordig gewoonlijk van een lengte die zich als getal grofweg in een getal van 410 cijfers laat uitdrukken. De <getal van 410 cijfers>e machtswortel uitrekenen is zelfs voor supercomputers te veel gevraagd. Echter, de sleutels heffen elkaar wiskundig op, waardoor als een bericht met de ene sleutel is versleuteld het kinderspel is het met de andere sleutel weer open te krijgen.
Ook met die wetenschap kom je echter niet verder. De veiligheid van het sleutelpaar is enigszins vereenvoudigd gebaseerd op het product tussen twee zeer lange priemgetallen, en door een serie bewerkingen krijg zitten geen van beide priemgetallen in de sleutels. Om, zelfs in het bezit van een van de sleutels, de andere te achterhalen, moet je het product ontbinden in de afzonderlijke priemgetallen. Zelfs voor een supercomputer is dat te veel gevraagd. Het is gewoon te duur en dan nog duurt het te lang om de moeite waard te zijn.
Maar omdat de principes zo eenvoudig zijn, is het dus onmogelijk om sterke cryptografie uit te bannen. Met de vele artikelen in de hand kan iedere redelijk bekwame programmeur zijn eigen RSA oplossing maken. Zelfs al zou je het voor elkaar krijgen om alle kopieën van de artikelen te vernietigen, dan nog kan iedere redelijk bekwame wiskundige met de wetenschap dat het kan op eigen houtje de principes herontdekken. Een organisatie als IS heeft dus aan een wiskundige en een bekwame programmeur genoeg om zijn eigen RSA te maken. Er is ook niets dat de cryptografische wereld daar tegen kan doen. Wiskundige wetten zijn per definitie voor iedereen gelijk.
Een tweede punt is dat veel van de retoriek er op gebaseerd is dat je cryptografie kan hebben die en kraakbaar voor opsporingsdiensten (en dan alleen nog met een gerechtelijk bevel in de hand) en onkraakbaar voor de rest kan zijn. Om dezelfde wiskundige reden is dit niet mogelijk. Iedereen die de wiskunde voldoende begrijpt kan achterhalen hoe een dergelijk algorithme werkt en voor eigen doel van dezelfde kwetsbaarheid gebruik maken.
Een alternatief zou zijn om, net zoals met de TSA approved locks is gebeurd, een database aan te leggen met kopieën van alle sleutels, althans voor zover de mensen zich aan deze ingevoerde verplichting houden om een kopie af te staan. Echter, het fenomeen van de genoemde sloten geeft meteen al een precedent nu de master sleutel printklaar op het internet staat - en de TSA in een reactie die als toonbeeld van bureaucratische onverschilligheid kan dienen al heeft aangegeven dat dit wat hun betreft geen probleem is omdat zij er nog steeds in kunnen (dat criminelen dat dus nu ook kunnen, daar kijken ze niet eens naar). Bovendien wordt een database met deze sleutels (denk onder anderen aan het hele digitale betalingsverkeer) meteen doelwit nummer 1.
Laten we weer terug gaan naar ons voorbeeld van de kaartjes voor de finale. Het sleutelpaar op de website heeft twee functies. Om te beginnen, als jij met de publieke sleutel een bericht versleutelt, kan iedereen het bericht verstuurd hebben, maar alleen de website kan het met de privesleutel lezen. Omgekeerd, als de website met de privesleutel een bericht versleutelt, kan iedereen het lezen, maar alleen de website kan het verstuurd hebben. Het ene ligt aan de grondslag van de versleuteling, het andere aan de digitale handtekening.
Beide principes vallen om op het moment dat de privesleutel niet meer prive is. Jij kan er niet van op aan dat het bericht (met daarin je creditcard nummer en eventuele andere toch wel kritische gegevens) niet onderweg door bijvoorbeeld IS (waarvan intussen bekend is dat ze creditcardfraude als financieringsbron gebruiken) gelezen wordt, en je kan er niet van op aan dat je wel met de organisator aan het praten bent en niet (ook) met IS, en dus daar je creditcardnummer aan geeft in plaats van aan de organisatoren.
Een ander voorbeeld. Een aantal PVV-ers hebben recent bezoek van de politie gehad vanwege kritische uitlatingen over het vluchtelingenbeleid. Even los van of je het eens of oneens bent met het beleid en hun reactie, het laat zien dat de dreiging van politiek getinte inmenging door opsporingsdiensten ook in Nederland nooit ver weg is. Je kan je kritiek versleutelen (en de andere partij laten signen zodat je weet dat je met deze praat), maar in geval van een database met sleutels encryptie is het zelfs niet nodig dat de sleutels uitlekt om dit scenario reëel te maken. En dit is niet op de PVV gericht, alle politieke hoofdstromingen zijn in hun begintijd een als staatsgevaarlijk vervolgde minderheid geweest en de meeste opvattingen die we als vanzelfsprekend beschouwen (zoals vrouwen- en homorechten, zorg voor het milieu, euthanasie en abortus) zijn ooit strafbaar geweest. Sommige zijn nog zowel strafbaar als salonfähig tegelijk (denk bijvoorbeeld aan euthanasie en softdrugs).
Conclusies zijn dus:
1. Het is niet mogelijk om criminelen uit te sluiten van onkraakbare encryptie, omdat volgens de wetten van de wiskunde dit nu eenmaal kan bestaan.
2. De wetten van de wiskunde sluiten uit dat je encryptie kan hebben die tegelijk zowel kraakbaar als onkraakbaar is.
3. Het hebben van een geheime opslagplaats van sleutels is een systeem dat even breekbaar is als een kristallen wijnkaraf. Het geringste scheurtje doet het in duizend scherven uiteenspatten.
4. Het hele maatschappelijke en economische verkeer, inclusief het betalingsverkeer, is voor zover dat online is afhankelijk van onkraakbare encryptie. Tornen aan dit principe neemt de terroristen het werk uit handen om de maatschappij en economie te ontwrichten.
22-04-2016, 13:05 door
SecOff
Door Erik van Straten:
Ik schat in dat er zit nog wel wat onderhandelingsruimte in het salaris zit....Door SecOff:
het maximale inkomen staan me wat tegen.Door Erik van Straten:Ik zoek een andere baan in midden Nederland (dit is geen hoax of zo). Heeft iemand een idee?
http://www.werkenbijavl.nl/vacatures/vacature-medewerker-informatiebeveiliging/Toch nog een kleine inconsistentie gevonden in jouw uitleg van de (hotel)schakelaars:
- als beide schakelaars in dezelfde stand staan (beide 0 of beide 1), is de lamp boven de trap uit;
- als de schakelaars in verschillende standen staan (een is 0 en de andere is 1), is de lamp boven de trap aan.
Dit klopt.
in het schema eronder (zal weer een hoop alt 255's hebben gekost :) ) zet je de schakelaar boven in stand 0 en beneden in stand 1. Het schemaatje als zodanig klopt, de standen van de schakelaars niet, die moeten in dit geval beide op 0 staan.
Ergo: volgens het schema is de lamp uit (stroomkring is verbroken), maar volgens de stand van de schakelaars is die aan.
Althans, zo begrijp ik het.
Overigens een heel duidelijk stuk, hoe je uitlegt, hoe encryptie werkt. Heb er van gesmuld!
Tzt mag je hier ook a-symmetrische encryptie uitleggen.
- als beide schakelaars in dezelfde stand staan (beide 0 of beide 1), is de lamp boven de trap uit;
- als de schakelaars in verschillende standen staan (een is 0 en de andere is 1), is de lamp boven de trap aan.
Dit klopt.
in het schema eronder (zal weer een hoop alt 255's hebben gekost :) ) zet je de schakelaar boven in stand 0 en beneden in stand 1. Het schemaatje als zodanig klopt, de standen van de schakelaars niet, die moeten in dit geval beide op 0 staan.
Ergo: volgens het schema is de lamp uit (stroomkring is verbroken), maar volgens de stand van de schakelaars is die aan.
Althans, zo begrijp ik het.
Overigens een heel duidelijk stuk, hoe je uitlegt, hoe encryptie werkt. Heb er van gesmuld!
Tzt mag je hier ook a-symmetrische encryptie uitleggen.
Ik schat in dat er zit nog wel wat onderhandelingsruimte in het salaris zit....
En dan nog, dat is zwaar onvoldoende beloning. Zulke advertenties zeggen veel over het gebrek aan professionaliteit aan de werkgeverszijde. En dan ook nog in Amsterdam! Ik denk niet dat er iemand met de gevraagde opleidingen reageert.
22-04-2016, 21:37 door
[Account Verwijderd]
-
Bijgewerkt: 22-04-2016, 21:43
[Verwijderd]
En dezelfde boodschap in cartoons:
http://dilbert.com/strip/2016-04-18
http://dilbert.com/strip/2016-04-19
http://dilbert.com/strip/2016-04-20
http://dilbert.com/strip/2016-04-21
http://dilbert.com/strip/2016-04-22
http://www.smbc-comics.com/index.php?id=4083
http://www.truthdig.com/cartoon/item/digital_back_door_20160307
https://twitter.com/danielsolove/status/701729120812597248
http://www.cagle.com/2016/03/first-they-came-for-the-iphones/
http://darylcagle.com/2016/02/21/apple-vs-the-fbi-and-third-world-despots/
http://dilbert.com/strip/2016-04-18
http://dilbert.com/strip/2016-04-19
http://dilbert.com/strip/2016-04-20
http://dilbert.com/strip/2016-04-21
http://dilbert.com/strip/2016-04-22
http://www.smbc-comics.com/index.php?id=4083
http://www.truthdig.com/cartoon/item/digital_back_door_20160307
https://twitter.com/danielsolove/status/701729120812597248
http://www.cagle.com/2016/03/first-they-came-for-the-iphones/
http://darylcagle.com/2016/02/21/apple-vs-the-fbi-and-third-world-despots/
23-04-2016, 09:46 door
karma4
Door Anoniem: En dan nog, dat is zwaar onvoldoende beloning. Zulke advertenties zeggen veel over het gebrek aan professionaliteit aan de werkgeverszijde. En dan ook nog in Amsterdam! Ik denk niet dat er iemand met de gevraagde opleidingen reageert.
Eens, het zegt genoeg over hoe medisch specialisten de IT specialisten waarderen. ... nauwelijks. Het zoontje van ... kan het ook wel. Die functie wordt wel ingevuld, kunnen ze altijd zeggen dat ze de mensen er voor aangenomen hebben.Door Anoniem:
En dan nog, dat is zwaar onvoldoende beloning. Zulke advertenties zeggen veel over het gebrek aan professionaliteit aan de werkgeverszijde. En dan ook nog in Amsterdam! Ik denk niet dat er iemand met de gevraagde opleidingen reageert.
Ik schat in dat er zit nog wel wat onderhandelingsruimte in het salaris zit....
En dan nog, dat is zwaar onvoldoende beloning. Zulke advertenties zeggen veel over het gebrek aan professionaliteit aan de werkgeverszijde. En dan ook nog in Amsterdam! Ik denk niet dat er iemand met de gevraagde opleidingen reageert.
Ik denk inderdaad dat er geen gekwalificeerde mensen zullen reageren.Typisch geval van volstrekt verkeerde inschatting door HR van de zwaarte van de functie icm met de gevraagde credentials. Verdubbel het salaris en er is een kans dat er iemand reageert. Het vasthouden aan de CAO slaat de plank volledig mis.
Voor de goede orde voor een andere reageerder: er is buiten de salarisgrenzen GEEN onderhandelingsruimte. Dit is een functie binnen de zorg...
Door Anoniem: En als pa of ma onverwacht wakker wordt?
Is natuurlijk ook mogelijk. Er kunnen diverse eigenaardige situaties ontstaan:A: Afgesproken: de lamp is aan = situatie veilig.
1. Pa of ma (of beiden) moeten ineens plassen, nét terwijl zusje naar boven sluipt, want: lamp aan is veilig. Die wordt betrapt en krijgt 4 weken huisarrest. Broertje krijgt volgende morgen een mep van zijn zus, hij had het licht uit moeten doen.
2. Pa of ma (of beiden) moeten ineens plassen. Na gedane zaken doen ze de lamp uit. (logisch, toch?) Zusje denkt: lamp is uit, dus onveilig en gaat wachten tot de lamp weer aan is.
sub-a: Broertje snurkt inmiddels, heeft niets gehoord van de escapades van z'n ouders; het is buiten 5 graden onder nul en zusje vriest dood, dan wel wordt zwaar onderkoeld de volgende ochtend in het ziekenhuis opgenomen. Pa vraagt na wat zusje 's nachts buiten deed, hoppa: 4 weken huisarrest, met aftrek van 1 dag, wegens opname ziekenhuis. Pa is best wel een reële vent. Zusje ramt later broertje een blauw oog.
3. zie situatie 2, maar pa en/of ma gaan gelijk weer slapen; doen het licht uit.
sub-b: Broertje werd wakker van al dat geplas, moest zelf dan ook weer plassen (dat soort geluiden werkt aanstekelijk) en doet het licht weer aan. Zusje sluipt naar boven en broertje krijgt de volgende morgen een reep chocola van zijn zus.
B: Afgesproken: de lamp is aan = situatie onveilig.
1. Pa of ma (of beiden) moeten ineens plassen, terwijl de lamp uit is. (veilig) Na gedane zaken doen ze de lamp weer uit. Zusje komt thuis -lamp uit-, dus veilig, broertje krijgt volgende morgen reep chocola.
2. Pa of ma (of beiden) moeten ineens plassen, terwijl de lamp uit is. Broertje wordt wakker van het geplas en doet gauw de lamp aan. Zusje wacht buiten en bevriest weer, ziekenhuis, enfin, 4 weken huisarrest en een blauw oog voor broertje, die zich de rest van zijn leven afvraagt: "Waarom? Ik heb het licht toch aangedaan?"
C: Afgesproken: de lamp is uit = situatie veilig.
Zie B-1 Ouders plassen met licht aan, zusje moet wachten tot ze klaar zijn, waarna het licht weer uit gaat, waarna zusje (bibberend) naar boven sluipt. Broertje volgende morgen chocola.
D: Afgesproken: de lamp is uit = situatie onveilig.
Zie B-2
Conclusies:
1. Zusje moet maar een andere hobby zoeken of wat vaker naar de kerk gaan, dan is dat zondige leven gelijk afgelopen, resultaat van dit soort hobby's kan dodelijk zijn;
2. Encryptie is op deze manier hartstikke moeilijk, vooral als Anoniemen á la 22-04-2016, 19:30 situaties creëren, die niet in een stroomschema zijn te vatten;
3. Pa en/of ma moeten met hun tengels van de schakelaars afblijven;
4. broertje en/of zusje lopen gerede kans om in het ziekenhuis te belanden: zusje door onderkoeling en broertje wegens totale uitputting (mag de hele nacht niet slapen, moet de verlichting regelen) of krijgt een hartvervetting van de chocola.
5. Ben benieuwd, hoe 20-04-2016 23:22 Anoniem hier een zinnig programma van kan maken.
Oplossing: Broertje kan het beste een rode (onveilig) of een groene (veilig) lamp uit zijn raam hangen, liefst een zwakke -. Als hij een sterke lamp gebruikt, bestaat het risico, dat 5 maanden later de ME binnenvalt. Waarom? Sterke lamp --> hoog stroomgebruik --> wietkwekerij!
Schrijver dezes kon vannacht niet slapen en was in een melige bui. Heeft zeker NIET de intentie, om het voorbeeld van Erik belachelijk te maken. Een beetje humor kan geen kwaad bij een serieus onderwerp.
Super post, deze zal veel mensen helpen een idee te krijgen hoe encryptie zoals simplere XOR cipher te werkt.
Encryptie is ook een van de balangrjike punten naast een certificaat enzo om ervoor te zorgen dat als je met iemand verbonden bent zoals je bank, dat de verbinding ertussen niet aangepast.
Als de inbreker die pakketje zou aanpassen dan zou bij het decrypten door de ontvanger niets nuttigs uitkomen behalve garbage data, de inbreker kent namelijk niet de encryptie key.
Als de encryptie methode verzwakt en voorspelbaar zou worden zouden, zou na het vinden van de methode door een hacker de ontvanger in gevaar zijn. Nog erger als dit in een Read only firmware zat zoals je router of CPU en je kreeg geen updates meer.
Een lange tijd geleden had Ik een batch script geschreven dat in Xor cipher specialiseerde.
Deze deed dit door vanaf plaintext elke ascii symbool (alleen de tekens die stomme Windows CMD niet stukmaakte) naar hexadecimaal om te zetten.
Dus van (Ascii "hond" > Hex "68 6f 6e 64").
Hierna elke hexadecimale teken naar binair zijn binaire tegenhanger.
Dus (Hex "6" > Bin "00110110" (dit had trouwens ook iets anders mogen zijn zoals "01010110" ofzo, zolang de decryptie methode maar gelijk aan de encryptie methode)).
Na de lijst was opgebouwd genereerde het aan de hand van de lengte van de volledige binaire text een random key die na gebruikt wordt om elke bit te wisselen van aan naar uit en uit naar aan.
Omwisselen in mijn script werkt alvolgt (Key '0' & Bin '0' > Cypher '0'), (Key '1' & Bin '1' > Cypher '0'), (Key '1' & Bin '0' > Cypher '1'), (Key '0' & Bin '1' > Cypher '1').
Dus onbewerkt ( Bin "00110110 00111000 00110110 01000110 00110110 01000101 00110110 00110100").
Willekeurig genereerde bits ( Random key "1001010101010111000110101100101011010110101101100101001100010011").
Uiteindelijke cyphertext ( Cyphertext "1010001101101111001011001000110011100000111100110110010100100111").
Om te decrypten doe je hetzelfde algoritme als het encrypten, alleen omgekeerd met de Random key over de cyphertext.
Zolang de (hacker) mijn Random key en algoritme niet heeft, wordt het heel moeilijk om mijn text te pakken te krijgen.
Ik heb dit zo simpel mogelijk als Ik kon geschreven, hoop dat iemand hiermee geholpen wordt ^_^.
Encryptie is ook een van de balangrjike punten naast een certificaat enzo om ervoor te zorgen dat als je met iemand verbonden bent zoals je bank, dat de verbinding ertussen niet aangepast.
Als de inbreker die pakketje zou aanpassen dan zou bij het decrypten door de ontvanger niets nuttigs uitkomen behalve garbage data, de inbreker kent namelijk niet de encryptie key.
Als de encryptie methode verzwakt en voorspelbaar zou worden zouden, zou na het vinden van de methode door een hacker de ontvanger in gevaar zijn. Nog erger als dit in een Read only firmware zat zoals je router of CPU en je kreeg geen updates meer.
Een lange tijd geleden had Ik een batch script geschreven dat in Xor cipher specialiseerde.
Deze deed dit door vanaf plaintext elke ascii symbool (alleen de tekens die stomme Windows CMD niet stukmaakte) naar hexadecimaal om te zetten.
Dus van (Ascii "hond" > Hex "68 6f 6e 64").
Hierna elke hexadecimale teken naar binair zijn binaire tegenhanger.
Dus (Hex "6" > Bin "00110110" (dit had trouwens ook iets anders mogen zijn zoals "01010110" ofzo, zolang de decryptie methode maar gelijk aan de encryptie methode)).
Na de lijst was opgebouwd genereerde het aan de hand van de lengte van de volledige binaire text een random key die na gebruikt wordt om elke bit te wisselen van aan naar uit en uit naar aan.
Omwisselen in mijn script werkt alvolgt (Key '0' & Bin '0' > Cypher '0'), (Key '1' & Bin '1' > Cypher '0'), (Key '1' & Bin '0' > Cypher '1'), (Key '0' & Bin '1' > Cypher '1').
Dus onbewerkt ( Bin "00110110 00111000 00110110 01000110 00110110 01000101 00110110 00110100").
Willekeurig genereerde bits ( Random key "1001010101010111000110101100101011010110101101100101001100010011").
Uiteindelijke cyphertext ( Cyphertext "1010001101101111001011001000110011100000111100110110010100100111").
Om te decrypten doe je hetzelfde algoritme als het encrypten, alleen omgekeerd met de Random key over de cyphertext.
Zolang de (hacker) mijn Random key en algoritme niet heeft, wordt het heel moeilijk om mijn text te pakken te krijgen.
Ik heb dit zo simpel mogelijk als Ik kon geschreven, hoop dat iemand hiermee geholpen wordt ^_^.
Het goed geschreven, maar nogal lange, verhaal van Erik van Straten laat zich zeer kort samenvatten. Erik definieert in woorden en met voorbeelden de bitoperatie "exclusive or" en bespreekt de eigenschappen van deze operatie.
Voor mensen die niet bang zijn van wiskundige notatie is de volgende samenvatting hopelijk verhelderend. Allereerst: er zijn verschillende symbolen in omloop voor "exclusive or" (zie https://en.wikipedia.org/wiki/Exclusive_or), maar laten wij deze operatie hier voor het gemak aanduiden met hoofdletter X. Verder zijn er drie bits in het spel: b1, b2, en b3.
De operatie X wordt gedefinieerd door de volgende twee regels:
Als b1 = b2 dan b1 X b2 = 0; als b1 != b2 dan b1 X b2 = 1.
(Het symbool != staat voor "niet gelijk aan").
Uit de definitie van X volgt:
b1 X b1 = 0.
De operatie X heeft de eigenschap:
(b1 X b2) X b3 = b1 X (b2 X b3).
Het feit dat de "exclusive or" dezelfde sleutel voor versleutelen en ontsleutelen heeft volgt uit:
(b1 X b2) X b2 = b1.
Deze regel wordt als volgt bewezen. Er geldt altijd:
(b1 X b2) X b2 = b1 X (b2 X b2) = b1 X 0.
Er zijn twee gevallen:
b1 = 1: (b1 X b2) X b2 = b1 X 0 = 1 = b1,
b1 = 0: (b1 X b2) X b2 = b1 X 0 = 0 = b1.
We kunnen dit resultaat bit voor bit toepassen op "bit strings" (rijen van bits). Als p de plain (onversleutelde) tekst als bit string is en k de key (sleutel) als bit string, dan wordt de gecodeerde tekst c gegeven door:
c = p X k.
Er geldt:
c X k = p want (p X k) X k = p.
In woorden staat hier dat de key k de string p versleutelt tot c en daarna c ontsleutelt tot p.
Voor mensen die niet bang zijn van wiskundige notatie is de volgende samenvatting hopelijk verhelderend. Allereerst: er zijn verschillende symbolen in omloop voor "exclusive or" (zie https://en.wikipedia.org/wiki/Exclusive_or), maar laten wij deze operatie hier voor het gemak aanduiden met hoofdletter X. Verder zijn er drie bits in het spel: b1, b2, en b3.
De operatie X wordt gedefinieerd door de volgende twee regels:
Als b1 = b2 dan b1 X b2 = 0; als b1 != b2 dan b1 X b2 = 1.
(Het symbool != staat voor "niet gelijk aan").
Uit de definitie van X volgt:
b1 X b1 = 0.
De operatie X heeft de eigenschap:
(b1 X b2) X b3 = b1 X (b2 X b3).
Het feit dat de "exclusive or" dezelfde sleutel voor versleutelen en ontsleutelen heeft volgt uit:
(b1 X b2) X b2 = b1.
Deze regel wordt als volgt bewezen. Er geldt altijd:
(b1 X b2) X b2 = b1 X (b2 X b2) = b1 X 0.
Er zijn twee gevallen:
b1 = 1: (b1 X b2) X b2 = b1 X 0 = 1 = b1,
b1 = 0: (b1 X b2) X b2 = b1 X 0 = 0 = b1.
We kunnen dit resultaat bit voor bit toepassen op "bit strings" (rijen van bits). Als p de plain (onversleutelde) tekst als bit string is en k de key (sleutel) als bit string, dan wordt de gecodeerde tekst c gegeven door:
c = p X k.
Er geldt:
c X k = p want (p X k) X k = p.
In woorden staat hier dat de key k de string p versleutelt tot c en daarna c ontsleutelt tot p.
Supergoed uitgelegd, Erik! Petje af.
Zelfs politici zouden dit toch voldoende moeten kunnen begrijpen! ;-)
Nog wat kleinigheden:
Dan lijkt het voor een leek net alsof je dat laatste bit steeds weer overschrijft.
Leesbaar gemakkelijker is dan misschien om "Outbit" eenvoudig meteen naar het bit
"BitNummer" van "OutputFile" te schrijven?
Dus:
In low level machinetaal (assembler) zou je bij sommige processors dit ook echt zo kunnen doen
namelijk met "bit clear" en "bit set" -instructies van een bepaald bitnummer in een bepaald register.
(hoewel het ook daar uiteraard met XOR veel efficiënter kan. Het ging hier vooral even om leesbaarheid voor de leek)
Nog 2 spelfoutjes:
Geen "Gebuikelijk" maar "Gebruikelijk"
geen "OuputFile" maar "OutputFile"
(voor het geval je deze lectuur nog eens professioneel zou gaan gebruiken)
Erik, heel veel succes bij het zoeken naar een nieuwe baan (zit wat in hetzelfde schuitje; iets ander hoofdvakgebied)
en ik hoop wel dat je op Security.nl je bijdragen blijft schrijven zodat ik/we er van kunnen blijven meeleren en genieten!
Dank,
Goeroehoedjes
Zelfs politici zouden dit toch voldoende moeten kunnen begrijpen! ;-)
Nog wat kleinigheden:
Schrijf "OutBit" naar "OuputFile" door de waarde helemaal achteraan te plakken;
Waarom zou je de waarde steeds helemaal achteraan plakken? Dan lijkt het voor een leek net alsof je dat laatste bit steeds weer overschrijft.
Leesbaar gemakkelijker is dan misschien om "Outbit" eenvoudig meteen naar het bit
"BitNummer" van "OutputFile" te schrijven?
Dus:
Schrijf de waarde van "OutBit" naar het huidige "BitNummer" van "OutputFile"
In low level machinetaal (assembler) zou je bij sommige processors dit ook echt zo kunnen doen
namelijk met "bit clear" en "bit set" -instructies van een bepaald bitnummer in een bepaald register.
(hoewel het ook daar uiteraard met XOR veel efficiënter kan. Het ging hier vooral even om leesbaarheid voor de leek)
Nog 2 spelfoutjes:
Geen "Gebuikelijk" maar "Gebruikelijk"
geen "OuputFile" maar "OutputFile"
(voor het geval je deze lectuur nog eens professioneel zou gaan gebruiken)
Erik, heel veel succes bij het zoeken naar een nieuwe baan (zit wat in hetzelfde schuitje; iets ander hoofdvakgebied)
en ik hoop wel dat je op Security.nl je bijdragen blijft schrijven zodat ik/we er van kunnen blijven meeleren en genieten!
Dank,
Goeroehoedjes
Allereerst mijn complimenten!
Wat betreft het volgende:
Maar dat terzijde, het ging immers om een voorbeeld.
Daarnaast ben ik het met veel van de posters eens dat het genoemde salaris niet in overeenstemming is met het gevraagde profiel.
Wat betreft het volgende:
Laten we het komende EK voetbal als voorbeeld nemen. Je bent optimistisch over de kansen van Oranje en bestelt alvast kaarten voor de finale.
Ehh, volgens mij is die kans op de finale precies 0. Eenvoudig, omdat ze niet mee doen.Maar dat terzijde, het ging immers om een voorbeeld.
Daarnaast ben ik het met veel van de posters eens dat het genoemde salaris niet in overeenstemming is met het gevraagde profiel.
Schrijf de waarde van "OutBit" naar het huidige "BitNummer" van "OutputFile"
of:Voeg (d.m.v. schrijven) de waarde van "OutBit" achteraan toe als het volgende bit in "OutputFile"
Trouwens (d.m.v. schrijven) kan je denk ik ook wel weglaten. Doet niet zoveel ter zake misschien?Zoiets lijkt me duidelijker, o.a. omdat het beter aanduidt dat "OutputFile" niet een vaste lengte heeft,
waardoor je als leek de zinsnede "door de waarde helemaal achteraan te plakken" verkeerd kunt interpreteren.
Je had dan beter kunnen schrijven: "...door de waarde er helemaal achteraan bij te plakken.
Dat zou al duidelijker zijn geweest.
Het is mijn bescheiden persoonlijke mening maar hoor Erik. Aan jou helemaal de keuze.
Maar ik ben zo vrij om deze feedback nog even te geven.
Goeroehoedjes
07-05-2016, 02:16 door
Erik van Straten
Dank aan allen voor de reacties!
@Goeroehoedjes: ik heb, tijdens het schrijven van het stuk, zitten dubben hoe ik "achteraanplakken" zou verwoorden, d.w.z. zonder het concept van een filepointer (een "vanzelfsprekend" concept voor ervaren programmeurs) uit te leggen en de tekst kort te houden. Ik heb er nu toch maar een stukje achtergezet in de hoop dat het nu begrijpelijker is, maar toch relatief kort blijft.
@Goeroehoedjes: ik heb, tijdens het schrijven van het stuk, zitten dubben hoe ik "achteraanplakken" zou verwoorden, d.w.z. zonder het concept van een filepointer (een "vanzelfsprekend" concept voor ervaren programmeurs) uit te leggen en de tekst kort te houden. Ik heb er nu toch maar een stukje achtergezet in de hoop dat het nu begrijpelijker is, maar toch relatief kort blijft.
Er is een kleine denkfout ingeslopen. Een belangrijke mogelijkheid is buiten beschouwing gelaten: een verbod op encryptie. Dit is, in ieder geval op wanneer gebruik gemaakt wordt van publieke netwerken, afdwingbaar voor wiskundig gegenereerde encryptie. block al het niet-leesbare verkeer.
toegegeven: de aloude variant op 'de beer is los' betekent eigenlijk 'we hebben een paar olifanten gezien' vang je hier niet mee af, maar strict genomen is dit geen encryptie.
Zelfs is het mogelijk om uitzonderingen te maken tussen vooraf bepaalde endpoints, zodat hiertussen wel encryptie mogelijk is.
toegegeven: de aloude variant op 'de beer is los' betekent eigenlijk 'we hebben een paar olifanten gezien' vang je hier niet mee af, maar strict genomen is dit geen encryptie.
Zelfs is het mogelijk om uitzonderingen te maken tussen vooraf bepaalde endpoints, zodat hiertussen wel encryptie mogelijk is.
09-05-2016, 20:23 door
Erik van Straten
09-05-2016, 13:44 door Anoniem: Er is een kleine denkfout ingeslopen. [...] block al het niet-leesbare verkeer.
Als dat in de praktijk zou kunnen werken, hadden we veel effectievere virusscanners. In de praktijk is de meeste informatie slechts leesbaar door de applicatie die er chocola van kan maken. Erger, we hebben veel last van applicaties die (exploitable) crashen doordat aanvallers "lijkt op" informatie produceren en (laten) aanbieden aan lekke applicaties.De kernvraag is: wat is leesbaar? Als je informatie (een bestand) met notepad.exe kunt openen, is het dan leesbaar?
In werkelijkheid bestaat informatie uit een X aantal bits die elk 0 of 1 kunnen zijn. Die zijn per definitie leesbaar.
Zeer goed artikel en fijn om te lezen!
Als tip, neem eens een kijkje bij Northwave (https://northwave.nl/)! :)
Als tip, neem eens een kijkje bij Northwave (https://northwave.nl/)! :)
In werkelijkheid bestaat informatie uit een X aantal bits die elk 0 of 1 kunnen zijn. Die zijn per definitie leesbaar.
En dus is ook versleutelde informatie leesbaar. De vraag is alleen: voor wie allemaal?Dit laatste is natuurlijk ook precies de vraag als je niet zou versleutelen.
Het lijkt me dat de keuze dan snel gemaakt is.
Goeroehoedjes.
Goed dat de in de USA (door senators Richard Burr en Dianne Feinstein) voorgestelde wet om backdoors in encryptie te verplichten, naar het land der fabelen is verwezen (zie bijv. [1] en [2]).
[1] http://www.theregister.co.uk/2016/05/27/backdoor_bill_dead/
[2] https://www.security.nl/posting/472416/Geen+steun+voor+omstreden+encryptiewetsvoorstel+in+VS
[1] http://www.theregister.co.uk/2016/05/27/backdoor_bill_dead/
[2] https://www.security.nl/posting/472416/Geen+steun+voor+omstreden+encryptiewetsvoorstel+in+VS
Reageren
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.
