Onderzoekers vinden kwetsbaarheden in zelfgemaakt encryptieprotocol van Threema

Onderzoekers zeggen een paar ernstige kwetsbaarheden te hebben gevonden in de versleutelde chatapp Threema. In een paper beschrijven ze zeven mogelijkheden om de encryptie te breken, al is misbruik in de praktijk verwaarloosbaar. Threema gebruikt inmiddels andere versleuteling.

Onderzoekers van de ETH Technische Universiteit van Zürich hebben hun bevindingen gepubliceerd in een paper. Ook hebben ze een website opgezet die Breaking The 3ma heet waarin ze hun belangrijkste bevindingen beschrijven. Threema is een beveiligde chatapp die gebruikmaakt van end-to-endencryptie op alle berichten. Daarvoor gebruikt het een zelfgemaakt cryptografisch protocol, maar sinds een paar weken heeft Threema een ander protocol, waardoor de ontdekkingen minder relevant zijn.

Volgens de onderzoekers zitten er diverse kwetsbaarheden in het oudere encryptieprotocol, maar is het daadwerkelijke gevaar klein. De onderzoekers delen de kwetsbaarheden in drie threat models. In alle drie die modellen is toegang nodig tot een server of het communicatiekanaal van slachtoffers, zelfs met een onvergrendeld toestel. Aanvallers met zulke toegang kunnen ook zonder de nieuwe encryptiekwetsbaarheden al veel informatie buitmaken.

Twee kwetsbaarheden kunnen plaatsvinden als een aanvaller zich op een netwerk richt. In dat geval is het mogelijk om permanente toegang te houden op een server als een aanvaller een ephemeral key bemachtigt. Threema gebruikt steeds wisselende sleutels, maar de onderzoekers tonen aan dat als een aanvaller op een client zo'n sleutel weet te bemachtigen, de aanvaller altijd toegang kan houden op de server. Een andere kwetsbaarheid draait om de vouch box, een soort container waarin een ephemeral key wordt gekoppeld aan een andere key. De aanvallers tonen aan dat ze een gebruiker een geldige vouch box key kunnen laten aanmaken waardoor ze zichzelf kunnen voordoen als legitieme client op de server.

Voor drie andere aanvallen is het nodig dat een aanvaller al toegang heeft tot een Threema-server. In dat geval is het bij een van de kwetsbaarheden mogelijk om de timestamp van verzonden berichten te manipuleren of berichten in een verschillende volgorde te laten afleveren, al kan de inhoud van berichten niet worden gelezen. Een andere kwetsbaarheid maakt het mogelijk om oude berichten terug te sturen naar een gebruiker als die de app op een nieuw apparaat installeert. Dat maakt replay attacks mogelijk, zeggen de aanvallers. Bij een derde kwetsbaarheid is het mogelijk een versleuteld bericht naar een andere gebruiker door te sturen, al zijn er ook bij die laatste twee aanvallen geen mogelijkheden om de inhoud van het bericht te lezen.

De onderzoekers beschrijven ook twee aanvallen waarvoor toegang nodig is tot een Android-toestel van een gebruiker. Als een aanvaller die heeft, kan hij een account kopiëren naar een tweede apparaat met een wachtwoord dat ter plekke wordt gekozen. Ook kunnen de onderzoekers een long term key kopiëren als een gebruiker de Threema Safe-cloudback-upfunctie gebruikt. Dat is een aanval die vergelijkbaar is met Crime, dat op tls-verbindingen kan worden toegepast.

De onderzoekers hebben hun bevindingen in oktober vorig jaar voorgelegd aan Threema. Dat heeft alle kwetsbaarheden gerepareerd. Inmiddels heeft Threema ook een nieuw encryptieprotocol, genaamd Ibex, waarin de kwetsbaarheden niet meer voorkomen. Desondanks is Threema niet te spreken over het onderzoek. Het bedrijf zegt dat de informatie sinds november vorig jaar, toen Ibex werd geïntroduceerd, niet meer relevant is en dat de daadwerkelijke impact nagenoeg non-existent is. Het bedrijf weerlegt alle losse kwetsbaarheden door te zeggen dat voor veel ervan ook nog social engineering of andere fysieke toegang tot een apparaat nodig is.

Zelf zeggen de onderzoekers dat hun onderzoek wel degelijk nut heeft, vooral als het gaat om securityaudits. Threema laat onafhankelijke audits uitvoeren, maar volgens de onderzoekers werd daarbij niet gekeken naar de aard van het cryptografische protocol zelf. Een van de onderzoekers waarschuwt tegen het gebruik van zelfgemaakt protocollen.

Reacties (45)

[Verwijderd]

Doordenkertje: als je één bit versleutelt met de beste versleuteling die we kennen, is de kans dat de waarde van dat bit niet verandert, 50%.

Als dat geen 50% is, spreken we van een bias en dat betekent meestal dat een encryptiealgoritme als gekraakt moet worden beschouwd.

Een One time pad is in principe onkraakbaar, maar vereist onhandig lange sleutels die zowel bij de versleutelaar als de ontsleutelaar bekend moeten zijn (en "volstrekt" random moeten zijn).

Omdat we dat niet practisch vinden verzinnen we allerlei trucs om met kortere sleutels te kunnen werken en om die sleutels zo veilig mogelijk uit te kunnen wisselen.

Van alle ooit verzonnen cryptografische protocollen zijn er nog maar bar weinig over die nog niet gekraakt zijn.

Voor geïnteresseerden: in 2016 schreef ik Encryptie voor leken - en waarom verzwakken onverstandig, en verbieden zinloos is

[- peter -]

Men zegt ook altijd tegen developers, don't roll your own crypto. En daar zit denk ik wel wat in.

[McBacon]

Er is wel een verschil tussen encryptie-algoritmes en -protocollen, maar mensen halen het vaak door elkaar. Een algoritme is bijvoorbeeld AES, een protocol is een set regels (zoals TLS) over hoe je communiceert en ook welke algoritmes je kan/mag gebruiken. "Don't roll your own crypto" gaat dus over zelfgemaakte algoritmes, want om dat goed te kunnen doen moet je behoorlijk wat weten van de moeilijkere soorten wiskunde. Je kan prima een eigen protocol bedenken, zolang je de algoritmes maar goed implementeert en daar heb je niet echt wiskunde voor nodig. Meestal is er niet veel meer vereist dan: zorgen dat je key lang genoeg en zo uniek en random mogelijk is, en geef altijd een unieke nonce/initialisation vector (normaal gesproken iets (pseudo)random). Hoe meer niet-vereiste opties je aanpast hoe meer kans er is dat je iets onveiligs aan het maken bent, de standaard waardes voor zulke opties zijn namelijk vaak in veel gevallen al veilig genoeg.

Er zijn sowieso genoeg developers die bestaande algoritmes al niet goed implementeren, kijk bijvoorbeeld naar Sony met de PS3. Als ik het me goed herinner gebruikten zij op bepaalde plekken altijd dezelfde IV, dus alles wat ze versleutelden met dezelfde key gaf altijd hetzelfde resultaat. Even simpel gezegd: ik encrypt "abc" (plaintext) en dat wordt dan "xyz" (ciphertext). De volgende keer dat ik "abc" encrypt moet het iets anders zijn dan "xyz", anders gebruik je dus dezelfde IV. Als je genoeg ciphertext hebt dan kun je mogelijk achterhalen welke plaintext bij welke ciphertext hoort, en daarmee zou je dus ook de key kunnen vinden. Gebruik je bijvoorbeeld iets "willekeurigs" zoals de huidige tijd in microseconden als IV, dan is de ciphertext elke microseconde dus anders en wordt het al een heel stuk lastiger (of misschien onmogelijk). De keys voor de PS3 waren daarom ook "gevonden" en niet "gekraakt".

Als ik op el interwebs zoek lijkt het erop dat Threema een eigen protocol bedacht heeft, gebaseerd op de NaCl crypto library. Dit is denk ik alleen wel het "oude" protocol waar het artikel het ook over heeft, ik zie zo even niet waar ze het mee hebben/gaan vervangen. Het zou dus goed kunnen dat ze bepaalde algoritmes uit die library gewoon niet helemaal goed geïmplementeerd hadden.

[Reactie gewijzigd door McBacon op 22 juli 2024 23:34]

[Anonymoussaurus]

Om eerlijk te zijn vind ik die vlieger niet altijd opgaan. Immers, een encryptieprotocol moet toch érgens beginnen. Je zou dan hetzelfde kunnen zeggen over het Signal Protocol; ook 'zelf' ontwikkeld. Of bedoel je te zeggen dat Threema's encryptieprotocol niet open-source is en Signal's wel? In het geval van het Signal Protocol kunnen er wel communityleden aan werken, omdat het open-source is: https://github.com/signalapp/libsignal

[J_van_Ekris]

Immers, een encryptieprotocol moet toch érgens beginnen.

Maar niet bij ontwikkelaars. Je moet echt veel verstand van crypto hebben om zoiets zelf te ontwerpen. Ik heb jaren college over de toepassing van cryptografie gegeven, en les 1 is: doe niets zelf, haal er een diepte-expert bij. Ik heb zelf vrij belangrijke crypto-toepassingen beoordeeld en ontworpen, en ik ben nu een jaar of 5 uit de diep-technische materie, en dan is zelfs aan mij het devies: laat je uitgebreid adviseren/helpen door mensen die er dagelijks mee bezig zijn. Ongemerkt lek je kennis over sleutels en kun je weer overnieuw beginnen. Maar als reguliere ontwikkelaar heb je gewoon te weinig kennis van zaken. Zo simpel is het.

[Reactie gewijzigd door J_van_Ekris op 22 juli 2024 23:34]

[MSalters]

De spiegelzijde hiervan is dat je veel verstand moet hebben van software engineering om libraries te maken, en crypto libraries zijn geen uitzondering.

Een belangrijke reden dat er zoveel roll-your-own crypto is, is omdat crypto libraries zo vaak ontwikkeld lijken te zijn door mensen die de benodige software engineering kennis missen. Dingen zoals X.509 en PKCS #12 kunnen in software engineering opleidingen gebruikt worden als een voorbeeld hoe het niet moet.

[Mushroomician]

Mag ik vragen wat je bedoelt met

Dingen zoals X.509 en PKCS #12 kunnen in software engineering opleidingen gebruikt worden als een voorbeeld hoe het niet moet.

Waarom zijn die twee voorbeelden van hoe het niet moet?

[Reactie gewijzigd door Mushroomician op 22 juli 2024 23:34]

[MSalters]

Daar is een rijtje redenen voor:

• Extreme complexiteit
• Veel te veel mogelijkheden
• De meeste van die mogelijkheden zijn niet veilig
• Er is geen helder gedocumenteerd proces om te kiezen welke mogelijkheden je moet gebruiken
• Onleesbare configuratie-files
• Troubleshooting als het niet werkt is niet goed over nagedacht

Zelf crypto schrijven leidt tot "security by obscurity", terwijl het verkeerd configureren van gangbare libraries leidt tot "insecurity by well-known flaws". Een ander bekend voorbeeld van "insecurity by well-known flaws" is SQL injection. Maar omdat SQL een stuk beter in elkaar zit, moet je behoorlijk incompetent zijn om daar in 2023 nog voor te vallen . Deze crypto-protocollen zijn wat dat betreft veel riskanter.

[Sysosmaster]

Bedoel je met X.509, SSL en of TLS?
want dat is niet hetzelfde.

voor X.509 zie ik niet hoe het veilig / onveilig is... want een X.509 is niet meer of minder dan een structuur en communicatie afspraak voor certificaten. de encryptie en verificatie zijn er extern aan.

[Rafe]

X.509 is misschien niet inherent onveilig maar het gebruik van ASN.1 heeft geleid tot meerdere vulnerabilities in implementaties. Recentelijk nog deze in iOS van vorig jaar (gerelateerd aan nieuws: 'FBI kraakte iPhone van San Bernardino-schutter met hulp Australisch ...) maar de lijst is lang: https://www.cvedetails.co...lts.php?q=ASN.1&sa=Search

[Sysosmaster]

Dit is een lijst met problemen zoals buffer overflows en gelijk..
niet iets dat specifiek met ASN.1 of X.509 te maken heeft.

Dat gezegd hebbende, het zijn wel foute die in de Bibliotheken zaten die gebruikt worden voor crypto (zoals OpenSSL).

dus het gaat niet over de Definities dat het probleem is... maar specifieke implementaties.
dus niet X.509 / ASN.1.. maar de TLS biliotheek van OpenSSL (als voorbeeld).

maakt het probleem niet minder erg, maar wel een ander probleem dan met x.509 / ASN.1

[Nightan]

Eens. X.509 en pkcs12 (.pfx) zijn gedrochten, maar er is niets mis mee. PKI is overal en dankzij Let's Encrypt is het internet een stuk veiliger geworden.

En wat is het alternatief? Stoppen met x.509 en PKI?

[J_van_Ekris]

De spiegelzijde hiervan is dat je veel verstand moet hebben van software engineering om libraries te maken, en crypto libraries zijn geen uitzondering.

Klopt, maar crypto vereist ook krankzinnig veel voorkennis van de achterliggende wiskunde, proces-algebra en information theory. En een enorm arsenaal aan parate veldkennis: er zijn letterlijk duizenden manieren om kennis over de crypttext of de sleutel te lekken waar je als leek niet bij stilstaat. Als iemand bij een ontwerp weer eens riep dat hij iets anders/beters had bedacht dan Rijndael/AES of Blowfish, dan sloten mijn collega's en ik al weer weddenschappen af.

Een belangrijke reden dat er zoveel roll-your-own crypto is, is omdat crypto libraries zo vaak ontwikkeld lijken te zijn door mensen die de benodige software engineering kennis missen. Dingen zoals X.509 en PKCS #12 kunnen in software engineering opleidingen gebruikt worden als een voorbeeld hoe het niet moet.

Tja, dat geldt voor vrijwel alles wat Open Source is (bij Closed Source is het wellicht slechter, maar die verbergen het beter): soms moet je niet onder de motorkap willen kijken. Zo heb ik in een duister verleden ooit de Linux True Random Generator onderzocht (echt tot deep, deep down in de Kernel), en dan kom je bij vrij essentiele onderdelen zeer cruciale ToDo's tegen. Op een gegeven moment is gewoon de tijd of de interesse op.

Maar dat een ander er een 99,9% versie heeft weten te maken die totaal onleesbaar is na jaren van commentaar, bugreports en fixes, betekent nog niet dat je als niet-specialist het in een keer wel goed gaat doen. De code ziet er misschien beter uit, maar ik ben altijd extreem sceptisch omdat je altijd wat over het hoofd ziet.

[hackerhater]

Die zin is wat te kort door de bocht.
Het komt erop neer dat je niet je eigen cryto moet maken als je er niet in gespecialiseerd bent.

[fevenhuis]

En de enigste manier om er in gespecialiseert te worden is door het zelf te maken.

Kip of ei verhaal.

Als je encryptie en de vallen echt wilt leren begrijpen zul je er toch echt zelf mee moeten stoeien i.p.v. een eindeloze reeks adviezen van anderen te geloven.

Ook voor encryptie geld vaak:
"Encryption is just your keys (or access backdoor/vulnerability) on someone else's computer". 😊

Bijkomstigheid is gewoon dat je een hele reeks vallen geleerd moet hebben voordat je op iets uit kan komen wat je overeind kunt houden.

Maar alle encryptie is begonnen met een hele kleine groep ontwikkelaars en soms ligt een vooruitgang gewoon op 1 klein gebied.

[RJG-223]

En de enigste manier om er in gespecialiseert te worden is door het zelf te maken.

Ehhh... Nee !

Net zoals je geen arts/chirurg wordt door maar zelf maar met mensen te gaan hobbyen. En zo kun je ook niet zelf een serieus vliegtuig maken, of een serieuze raket door het zelf te gaan doen. Een papieren vliegtuigje gaat natuurlijk wel lukken, of een simpele vuurpijl. Je zult in al die gevallen, net zoals bij cryptografie, moeten beginnen met een degelijke, gespecialiseerde opleiding op universitair niveau. Trek daar maar minstens 4 jaar full-time studie voor uit. Dat is je basis. Daarna moet je nog vele jaren gespecialiseerde ervaring opdoen, om uiteindelijk op een niveau te komen dat je zelf zoiets kunt.

Als je encryptie en de vallen echt wilt leren begrijpen zul je er toch echt zelf mee moeten stoeien i.p.v. een eindeloze reeks adviezen van anderen te geloven

Nee. Goede encryptie bestaat uit een goed algoritme, waarvoor je dus een goede wiskundige basis (universitaire opleiding) nodig hebt. Daarnaast kan een goed algoritme door een onbenullig detail in de implementatie toch kwetsbaar zijn. Dus je moet niet alleen verstand hebben van wiskunde, maar ook van de (alle!) manieren waarop bestaande encryptiealgoritmen tot nu toe zwak zijn gebleken, zodat je die kunt vermijden, en zodat je ook zo veel mogelijk nieuwe zwaktes kunt vermijden. Daarbij kan het ook blijken dat jouw theoretisch goede encryptiealgoritme niet veilig geïmplementeerd kan worden. En als je na al je moeite een nieuw algoritme hebt, dan bedenkt een vage onderzoeker in een vreemd land een truukje, waardoor jouw implementatie toch ineens kwetsbaar is. Hij stopt bijvoorbeeld de computer die de encryptie uitrekent in een magnetron, waardoor die computer rekenfouten maakt, waardoor de encryptie gekraakt wordt.

Dat alles kun jij niet (en niemand niet) op z'n zolderkamertje zelf bedenken, en niet door er zelf mee te 'stoeien'. De kennis en ervaring krijg je alleen door langurige studie. Door te luisteren naar mensen die er wel verstand van hebben, en te leren van hun ervatring, en hun fouten...

"Encryption is just your keys (or access backdoor/vulnerability) on someone else's computer"

Die uitspraak ging over de cloud, en niet over encryptie. Je kunt dan wel het woord 'cloud' door 'encryptie' vervangen, en 'data' door 'keys', maar dat betekent nog niet dat je een zinnige uitspraak krijgt.

Afgezien daarvan: of een encryptiealgoritme zwak is of niet, heeft helemaal niets te maken met op welke computer het draait. Dus die hele opmerking is sowieso niet relevant in deze context.

[fevenhuis]

Dat is dus het grote fabeltje van encryptie, dat alles draait om 1 algoritme als totaaloplossing. We hebben het over protocollen die op vele wiskundige principes gebaseerd zijn.

Een goede kennis van wiskunde is wel vereist ja, maar dat hoeft tegenwoordig ook niet meer via een universiteit. Ik denk dat er voldoende mogelijkheden zijn om jezelf in wiskunde te verdiepen zonder dat via een universiteit te doen. Iemand met een talent voor wiskunde zal daar iets mee kunnen doen.

Het voordeel van een universiteit is de toegang tot een gecentraliseerde en goed onderhouden documentatie.

[Reactie gewijzigd door fevenhuis op 22 juli 2024 23:34]

[RJG-223]

Dat is dus het grote fabeltje van encryptie, dat alles draait om 1 algoritme als totaaloplossing. We hebben het over protocollen die op vele wiskundige principes gebaseerd zijn.

Het draait niet om één algoritme. Er zijn vele mogelijkheden. Maar het is niet zo makkelijk om een goed algoritme te maken. Dát is de reden dat er zo weinig goede algoritmes zijn. En omdat het aantal mensen op de wereld wat een goed algortime kan maken op de vingers van een hand, of misschien twee te tellen is.

Een goede kennis van wiskunde is wel vereist ja, maar dat hoeft tegenwoordig ook niet meer via een universiteit. Ik denk dat er voldoende mogelijkheden zijn om jezelf in wiskunde te verdiepen zonder dat via een universiteit te doen.

Theoretisch zou dat kunnen, maar er is waarschijnlijk op dit moment geen enkele persoon op de aarde die wiskunde-kennis heeft op het niveau dat nodig is om een encryptiealgoritme te kunnen maken zonder elementaire fouten te maken, maar dat niet op een unversiteit geleerd heeft. Je kunt net zo goed zeggen dat iemand piloot kan worden door zelfstudie, zonder naar een pilotenopleiding te gaan. Of chirurg. Theoretisch zou je de kennis en ervaring misschien op die manier op kunnen doen, maar van alle 8 miljard mensen is er zo goed als zeker geen één levende ziel wie dat ook gelukt is. En anders houd ik me aanbevolen: vertel me maar wie het wél, aantoonbaar, gelukt is (dus niet iemand die het enkel beweert, maar iemand die ook erkend is om zijn kennis en/of vaardigheden: die een baan heeft waarbij die vaardigheden vereist zijn).

Iemand met een talent voor wiskunde zal daar iets mee kunnen doen.

Als hij Ramanujan heet, dan héél misschien. Ramanujan had misschien een geschikt wiskundig algoritme kunnen bedenken,. Hij wel. Maar dan nog moet zo'n algoritme ook bestand zijn tegen domme zwakheden, bijvoorbeeld van onderzoekers die de computer in de magnetron stoppen. En dat had zelfs Ramanujan niet kunnen bedenken - daar was hij waarschijnlijk te wiskundig voor...

Ik zou zeggen: in plaats dat je vanuit je luie stoel bedenkt dat alles wat andere mensen doen makkelijk is, en dat iedereen het kan: ga een (zelf)studie doen. Als iedereen het kan, ga het dan zelf doen, en bewijs dat jij het ook kunt. Anders is het alleen gebakken lucht uit jouw mond. Ik kan ook beweren dat ik minister-president zou kunnen worden, of piloot, of cryptoexpert, maar tenzij ik dat dan ook doe, is het gewoon lege snoeverij. Dan ben ik gewoon een tweede Rian van Rijbroek

[fevenhuis]

U bent, in nog veel meer tekst, mijn comments opnieuw aan het uitschrijven.

[J_van_Ekris]

Je zult in al die gevallen, net zoals bij cryptografie, moeten beginnen met een degelijke, gespecialiseerde opleiding op universitair niveau. Trek daar maar minstens 4 jaar full-time studie voor uit. Dat is je basis. Daarna moet je nog vele jaren gespecialiseerde ervaring opdoen, om uiteindelijk op een niveau te komen dat je zelf zoiets kunt.

En dan nog. Er zijn maar weinig echt breed getoetste encryptie-algoritmes, waarbij de leeftijd vaak in decennia wordt gemeten. De mannen van Rijndael produceren in hun werkende leven waarschijnlijk maar één algoritme. Schneider geloof ik twee (als je TwoFish niet meetelt). En dan heb je het over de absolute top van de pyramide, betere cryptografen hebben we niet. Het is niet dat die mannen lui zijn, maar omdat hun vak zo razend complex is. En goed toepassen van dat soort complexe algoritmesop de juiste data is dan al een grote uitdaging.

[fevenhuis]

Inderdaad de meeste nieuwe encryptie standaarden uit het verleden zijn gemaakt door mensen die een nieuwe standaard op de bestaande gedocumenteerde soorten encryptie zwakheden hadden gebouwt.

Dit was in het verleden vaak een langdurig process, maar vandaag de dag met de huidige staat van documentatie en technologie is de ontwikkeltijd voor nieuwe theorethische encryptie alswel praktische toepassing er van velen malen korter.

Het feit dat het vroeger allemaal zo lang duurde om iets te onwikkelen wil niet zeggen dat het nu nog steeds zo lang moet duren.

[J_van_Ekris]

Dit was in het verleden vaak een langdurig process, maar vandaag de dag met de huidige staat van documentatie en technologie is de ontwikkeltijd voor nieuwe theorethische encryptie alswel praktische toepassing er van velen malen korter.

Het feit dat het vroeger allemaal zo lang duurde om iets te onwikkelen wil niet zeggen dat het nu nog steeds zo lang moet duren.

Hoe oud was AES ook al weer? Bij mijn weten 25 jaar namelijk....

Ik denk dat je de vereiste kennis en inzicht enorm onderschat. Dit gaat er niet om dat je iets moet kunnen Googlen, maar dit moeten mensen zijn die na een hele serieuze universitaire studie van jaren en decennia van onderzoek zoveel inzicht en gevoel hebben ontwikkeld dat ze een degelijk algoritme kunnen ontwerpen. En dan, heel heel misschien haalt dat algoritme de lijst van degelijke algoritmes. Dit zijn de Cruijff's van de informatica.

En dat wordt zeker niet simpeler. Waar 25 jaar geleden dat echt alleen ging om de bestendheid tegen brute force aanvallen of slimmere raadtrucs waarmee je de solutionspace kon partitioneren, komt er tegenwoordig een hele lange lijst van aanvullende eisen bij waarbij men er ook vanuit gaat dat de CPU en Memory logisch en fysiek bekeken kunnen worden. Als er een groep van mensen betere tools heeft gekregen zijn het de cryptoanalisten.

De mindere goden volgen hetzelfde pad als de Cruyffs, maar zullen "blijven steken" in het goed toepassen van die algoritmes, wat al een vak op zich is. Want hoe goed een algoritme ook is, het toepassen daarvan zonder informatie te lekken is al krankzinnig complex. En dan kom je al snel op entropiediscussies uit waar weer die discrete wiskunde en getaltheorie opduikt. Dus nee, dit is geen plek voor autodidacten.

[fevenhuis]

Dat het niet meer alleen om brute force bestendigheid gaat is exact waar ik het over heb.

Er zijn er sinds AES dus een heleboel soorten encryptie bijgekomen, oftewel veel kortere onwikkeltijd.

Over AES:
nieuws: Onderzoekers leggen kwetsbaarheid in AES-encryptie bloot

Inmiddels wordt alleen AES-512 als veilig beschouwd.

Onder kortere ontwikkeltijd versta ik ook de onwikkeltijd van exploits.

[J_van_Ekris]

Onder kortere ontwikkeltijd versta ik ook de onwikkeltijd van exploits.

Ik denk dat je de ontwikkeling van cryptografische algoritmes en protocollen verwart met het kraken daarvan.

[fevenhuis]

Nee, ik denk dat het onwikkelen van een cryptografisch protocol nauw verbonden is aan de weerbaarheid tegen zwakheden (aka. Kraken).

Ik verwar dus helemaal niets, het is exact dezelfde materie.

[J_van_Ekris]

Nee, ik denk dat het onwikkelen van een cryptografisch protocol nauw verbonden is aan de weerbaarheid tegen zwakheden (aka. Kraken).

Want een goed huis ontwerpen vereist dezelfde competenties als een huis afbreken?

Iets ontwerpen en bouwen, waarbij eisen vertaald moeten worden naar concrete oplossingen, is echt iets anders dan het doorgronden en er kwetsbaarheden in aanwijzen. Daardoor is een cryptografisch algoritme ontwerpen echt een heel ander vakgebied dan het zoeken van zwakheden ervan. Cryptoanalisten zien zeker dingen die in algoritmes die nuttig zijn voornieuwe ontwerpen, maar iets doorgronden is echt iets anders dan zelf ontwerpen.

[fevenhuis]

Huizen bouwen en encryptie ontwikkelen zijn inderdaad verschillende zaken.

U bent zelf degene die nu een argument probeert te creeren door deze zaken met elkaar te verbinden. Onduidelijk en misplaatst.

Het is toch echt zo simpel als dat encryptie ontwikkeld wordt TEGEN ZWAKHEDEN, zonder kennis van de mogelijke zwakheden wordt er dus alleen gewerkt aan een wiskundige theorie (zonder toepassing).

[Nightan]

Heb je een bron? Want volgens mij is AES 128 bit veilig genoeg. 256 als het echt super super veilig moet zijn, maar is vaak overkill.

[bwerg]

Als je encryptie en de vallen echt wilt leren begrijpen zul je er toch echt zelf mee moeten stoeien i.p.v. een eindeloze reeks adviezen van anderen te geloven.

Dat is toch echt wat te gemakkelijk bedacht. Je hebt echt een flinke basis wiskunde nodig, dat leer je niet door te stoeien maar door gedegen onderwijs te volgen. Autodidactiek lijkt me in de crypto niet haalbaar, tenzij je effectief gewoon een complete theoretische zelfstudie doet. Nadenken over puur de protocollen en niet over de encryptie zelf is nog haalbaar, maar dan alsnog erg foutgevoelig en je moet wel echt weten hoe je gestructureerd redeneert over de gewenste eigenschappen.

[Reactie gewijzigd door bwerg op 22 juli 2024 23:34]

[J_van_Ekris]

Dat is toch echt wat te gemakkelijk bedacht. Je hebt echt een flinke basis wiskunde nodig, dat leer je niet door te stoeien maar door gedegen onderwijs te volgen.

Laat dat basis maar weg. Het heeft een hele wiskundige basis, maar het nivo is verre van basis. Dit is gewoon krankzinnig taaie wiskunde, met name de hoek van de discrete wiskunde en getaltheorie die de basis van de crypto vormen zijn echt taai en soms moeilijk te volgen. Ik heb op de universiteit behoorlijk goede docenten gehad, maar ik heb discrete wiskunde ook vier keer examen mogen doen (en het vak zelfs twee keer gevolgd).

Procesalgebra en informatietheorie zijn nog wel wat toegankelijker, maar dat kan ook zijn dat ik tegen de tijd dat ik die vakken kreeg al zoveel wiskunde voor mijn kiezen had gehad dat ik er al aan gewend was. Kan me niet voorstellen dat je dat jezelf even in een weekje eigen maakt eerlijk gezegd. Zeker niet door "spelen" met code.

Autodidactiek lijkt me in de crypto niet haalbaar, tenzij je effectief gewoon een complete theoretische zelfstudie doet. Nadenken over puur de protocollen en niet over de encryptie zelf is nog haalbaar, maar dan alsnog erg foutgevoelig en je moet wel echt weten hoe je nadenkt over de gewenste eigenschappen.

En onderschat dan ook niet de behoorlijk steady stroom van nieuwe cryptografische technieken niet die je actueel moet houden. Toen ik begon was het een zuiver algoritmisch gebeuren: kon je de de versleutelde tekst of de sleutel achterhalen door zwaktes in het algoritme te vinden. Dat is nog steeds een sport, maar tegenwoordig kijkt men al naar CPU eigenschappen, memory zwaktes, etc. om datzelfde te bereiken. Dat goed bijhouden is al een vak apart.

[fevenhuis]

Inderdaad eem goede wiskundige basis is vereist, maar nog veel belangrijker is de kennis over vulnerabilities van soorten encryptie alswel sotware.

Mensen vergissen zich vaak dat alles draait om een encryptie welke nog meer processorkracht vereist om te kraken, maar in werkelijkheid gaat het vaak over onverwachte zwakheden in hardware of software of gewoonweg logica wat de doorslag geeft of een nieuwe encryptie standaard het haalt of faalt.

Desalniettemin het begint veelal met een wiskundige basis theorie.

Een groot deel van bestaande encryptie zwakheden zijn natuurlijk gedocumenteerd en het is op deze documentatie waarop nieuwe emcryptie protocollem rusten.

En dan hebben we nog een factor, het verborgen houden van zwakheden om anderen voor te blijven. Niet alle zwakheden worden blindelings gerapporteerd en gedocumenteerd en alleen door zelf encryptie software te schrijven zul je deze vinden.

[hackerhater]

Klopt, maar je zal sowieso de onderliggende theorie moeten snappen.
En zolang je het leren bent (het stoeien ermee), het absoluut niet in productie gebruiken.

[RobertMe]

Het is natuurlijk altijd een afweging. Maar ik denk dat je 90% van de developers zoiets gewoon niet moet laten doen. Dit moet je echt over laten aan mensen die verstand hebben van cryptografie etc. En wellicht kunnen die kenners ook programmeren en het dus zelf implementeren, en anders krijg je heel mooie design documenten die een developer kan implementeren.

In zoverre dus eigenlijk zoals ook standaard is bij het ontwikkelen van (business) applicaties. Een developer is geen domein kenner. Daarvoor zijn andere mensen en die moeten, al dan niet in combinatie met een tussenpersoon (bv requirements engineer) zorgen dat voor de developers duidelijk is wat ze moeten maken.
Als ik (als fulltime developer) een of andere financiële applicatie zou moeten bouwen zou ik ook 90% van bv de belastingregels over het hoofd zien / niet kennen en fout implementeren. Daarbij zou iemand anders mij dus moeten bijstaan en beschrijven hoe het moet werken, zodat ik de code kan kloppen.
Waarom developers dan wel "even" hun eigen cryptografie op zouden moeten kunnen zetten is mij een raadsel.

[Reactie gewijzigd door RobertMe op 22 juli 2024 23:34]

[Kriekel]

Het gaat niet alleen om de kennis hebben om het correct te implementeren, maar het bedrijf moet ook de resources hebben om intern te testen of het daadwerkelijk veilig is. Daarnaast moet je dan ook blijven updaten zodat je altijd aan de laatste eisen voldoet, terwijl het backwards compatible blijft.

Dus om dit betrouwbaar te kunnen doen moet je bij een multinational werken, of bij een bedrijf wat op cryptografie is gespecialiseerd.

[bwerg]

Maar ik denk dat je 90% van de developers zoiets gewoon niet moet laten doen.

Nog veel meer dan 90%. Zeker als het op de cryptografie zelf aankomt. De meeste developers hebben gewoon kennis van algemene programmeertalen en programmeeromgevingen, dan weet je net zoveel van crypto implementeren als dat iemand met een rijbewijs weet van een automotor in elkaar zetten.

Zie hoeveel ontwikkelaars nooit diepgaand onderwijs in de wiskunde gevolg hebben, laat staan in de cryptografie: een significante groep ontwikkelaars is zelf-onderwezen, heeft het via een omscholingscursus opgepakt, etc. Dat terwijl je cryptografie nu toch alleen op een universiteit kan leren, waarvan zelfs slechts een klein deel van de studenten in informatica-richtingen daarvoor kiest, en een nog kleiner deel daar zodanig diep induikt om dat ook echt op serieuze schaal te kunnen oppakken. Nou kun je het in theorie natuurlijk ook buiten een opleiding om leren maar ik vraag me af hoe veel mensen dat doen: i.t.t. andere deelgebieden in de software-ontwikkeling is "learning on the job" bij crypto nogal riskant. En lastig, aangezien je toch een bak wiskunde als basis nodig hebt.

Dus verander die 90% maar in minstens 99,9%.

[Reactie gewijzigd door bwerg op 22 juli 2024 23:34]

[Raymond Deen]

Het moet helemaal niets uitmaken of je de bron of niet hebt; voor een goed encryptieprotocol is het wel of niet open source zijn echter geen vereiste, hooguit maakt het het bewijzen dat het een goed of slecht protocol is makkelijker.

Encryptie is wiskunde, verpakt in goede programmering. Dus het begint bij de wiskundige die diepe kennis heeft van enryptie. Daarna kan deze door slecht programmeerwerk op talloze manieren alsnog verkloot worden; een programmeur met gedegen kennis van veilig ontwikkelen en goede skills is dus óók onontbeerlijk.

Daarna pas komt dan de wens of het bedachte dan ook open source moet zijn/worden. En dat ligt maar net aan de eigenaars en hun doel met dez code. Je hoeft jouw fantastische code natuurlijk niet perse met de wereld te delen.

[Oon]

Maar ook Signal maakt gebruik van de opties die er zijn, ze hebben misschien wel een eigen library geschreven maar 'deep down' zijn ze niet zomaar wat aan het verzinnen.

Er zijn gewoon opties die de komende 10-15 jaar niet te kraken zijn, en ja die zijn ook ooit door iemand geschreven, maar die zitten al enkele jaren in alle gangbare programmeertalen verstopt. Waarom zou je in godsnaam nu nog zelf iets gaan bedenken?

Tegen de tijd dat het nodig is heeft een of andere onderzoeker met meer kennis dan jijzelf wel weer een ander algoritme bedacht dat wiskundig gezien onkraakbaar is en weer een paar decennia mee kan.

[spoonman]

Waarom zou je dat ook willen doen?

[Jeoh]

Sommige mensen denken altijd dat ze het beter kunnen doen. Soms is dat zo, vaak niet.

[RJG-223]

Sommige mensen denken altijd dat ze het beter kunnen doen. Soms is dat zo, vaak niet.

Meestal speelt in dit soort gevallen het Dunning-Kruger effect een grote rol...

[jwal]

Ik weet er het fijne niet van maar heb wel eens gelezen dat de cia enigszins betrokken is (geweest?) bij stukken van encryptiecode. Stel dat dat waar is en ze zouden daardoor een backdoor hebben, in dat geval zou het wel slim zijn om je eigen encryptie te rollen.
Misschien weet iemand anders of een geheime dienst inderdaad betrokken is..

[haven]

Mogelijk dat je doelt op de invloed van National Security Agency (NSA) op Data Encryption Standard (DES). Bij deze oude en achterhaalde encryptie standaard uit de jaren 70 is ooit voor sleutels met een lengte van 56bit gekozen. Het vermoeden is dat deze lengte ervoor zorgde dat de Amerikanen deze encryptie konden kraken. DES werd al snel aangevuld met een combinatie van 3 x DES die bekend is als 3DES of Triple DES. Tegenwoordig wordt AES gebruikt.

[Adm.Spock]

De NSA had de beschikking over zeer krachtige computers om encryptie met "brute force" te kraken, maar ontdekten ook dat een zwakheid in DES zat die differentiële cryptoanalyse mogelijk maakte, effectief een achterdeur. Door aanpassingen aan de "S-boxen" hebben ze effectief deze achterdeur dichtgetimmerd.
Ze hebben daarbij ook gelijk de gelegenheid aangegrepen om de sleutellengte tot 56bit te beperken (overigens een compromis, de NSA wilde eigenlijk 48bits, origineel had IBM 64 bit voorgesteld).
Maar aangezien op dat moment alleen de overheid van de VS over een computer beschikte die in korte tijd de 48 bit sleutels kon kraken (56 bit duurt al significant langer, laat staan 64 bit), werd dit niet als zwakte beschouwd. Al werden ze al snel door de realiteit ingehaald, de ontwikkeling van steeds snellere computers ging in die periode enorm snel.

TLDR; de NSA heeft ervoor gezorgd dat DES van "lek als een mandje" naar "sterk genoeg voor nu" ging.

[J_van_Ekris]

Mogelijk dat je doelt op de invloed van National Security Agency (NSA) op Data Encryption Standard (DES).

Misschien ook even ter verduidelijking omdat veel mensen bepaalde associaties met de NSA hebben: de NSA is eigenlijk de centrale cryptoclub van de Amerikaanse geheime diensten. Naast afluisteren (en dus kraken) zijn ze ook verantwoordelijk voor de beveiliging van geheime overheids-informatie (zie https://en.m.wikipedia.org/wiki/National_Security_Agency). Het is dus absoluut niet vreemd dat de NSA zich met de ontwikkeling van DES en het latere AES bemoeide: ze zijn verantwoordelijk namens de Amerikaanse overheid voor de goedkeuring voor overheidsgebruik.

[Yzord]

Als ik het zo lees dan komt bij mij de gezegde van een mug een olifant maken naar boven. Ja, het is mogelijk allemaal, maar er moet teveel gebeuren om het mogelijk te maken.

Op basis van deze feiten kan ik ook roepen dat de encryptie van Whatsapp te kraken is, want ik heb al toegang tot de Whatsapp servers waar de private keys staan, om maar even een krom voorbeeld te noemen.

Wat me wel aan het denken zet is of ze het nieuwe protocol hebben ingevoerd dankzij deze "wetenschappers" of dat deze al op de roadmap stond. Ik denk eerder gezegd het laatste, want zoiets bedenk je niet ff in een paar weken.