AIVD waarschuwt organisaties voor dreiging quantumcomputers voor cryptografie

De AIVD roept organisaties op om actief na te denken over het beschermen van gevoelige data tegen de quantumcomputer. De veiligheidsdienst doet een oproep aan IT-beveiligers om voorbereidingen te treffen voor de impact die quantumcomputers gaan hebben op cryptografie.

Experts verwachten dat we nog circa 10 tot 20 jaar verwijderd zijn van een quantumcomputer die de huidige cryptografische standaard kan kraken. De kans dat dit al in de komende tien jaar gebeurt is klein, maar volgens de AIVD is het belangrijk dat organisaties nu al passende maatregelen nemen.

Maatregelen zijn nu al noodzakelijk volgens de AIVD, omdat quantumcomputers mogelijk sneller in staat zijn de huidige cryptografische standaarden te kraken dan nu wordt verwacht. Daarnaast kan de data die nu versleuteld wordt verstuurd ergens onderschept worden en dan jaren later alsnog worden ontcijferd. Daarom wil de veiligheidsdienst organisaties met een brochure wijzen op de voorzorgsmaatregelen die ze kunnen nemen.

De AIVD noemt als oplossing 'post-quantumcryptografie'. Deze vorm van cryptografie is gebaseerd op wiskundige problemen die moeilijk zijn te kraken door quantumcomputers. Goede standaarden van dit type cryptografie zijn volgens de AIVD 'nog niet volwassen', maar organisaties kunnen hun systemen al wel voorbereiden op de komst van deze nieuwe standaarden.

Tot slot adviseert de AIVD om gevoelige data die niet naar buiten mag komen te beveiligen met zowel een laag asymmetrische cryptografie als een laag symmetrische cryptografie. Ook kan het een overweging zijn om echt gevoelige data helemaal offline te halen, aldus de veiligheidsdienst.

Tests met quantumcomputers hebben de afgelopen jaren al laten zien dat specifieke berekeningen veel sneller uit kunnen worden gevoerd dan met een gewone computer. Tot nu toe is de ontwikkeling van deze quantumcomputers nog niet in een stadium waarbij deze technologie ingezet kan worden voor het kraken van cryptografie, al wordt er met regelmaat een nieuwe doorbraak geclaimd door onderzoekers, bijvoorbeeld door Google in 2019 en afgelopen zomer nog door China.

Door Robert Zomers

Redacteur

23-09-2021 • 18:46

81

Reacties (81)

Sorteer op:

Weergave:

Experts verwachten dat we nog circa 10 tot 20 jaar verwijderd zijn van een quantumcomputer die de huidige cryptografische standaard kan kraken.
Misschien goed om dit iets specifieker te maken, want het gaat specifiek om asymmetrische cryptografie zoals RSA. Dit soort cryptografie is veilig omdat het ontbinden in priemfactoren van grote getallen een wiskundig moeilijke puzzel is. Als je dit probleem kan oplossen (of makkelijker kan maken), dan zijn deze algoritmes ineens niet meer zo veilig. Dat is precies wat het quantumcomputeralgoritme van Shor voor elkaar kan krijgen (https://en.wikipedia.org/wiki/Shor%27s_algorithm), op dit moment zijn quantumcomputers nog niet voldoende ontwikkeld om dit algoritme praktisch in te zetten maar er wordt dus voorspeld dat dit binnen 10-20 jaar wel zo is.

Symmetrische cryptografie is niet op dit wiskundige probleem gebaseerd en is dus niet kwetsbaar voor deze toepassing van quantumcomputers.

[Reactie gewijzigd door Mathijs1 op 23 juli 2024 06:33]

Het is nog maar de vraag of dat we nou echt 10-20 jaar hiervan verwijderd zijn.

De geschiedenis heeft al vaak genoeg aangetoond dat wat in "geheime bunkers" door overheden word ontwikkeld enkele jaren voorop loopt op wat publiekelijk bekend is. Landen als Amerika, Israël, China en Rusland bevinden zich altijd in een technologische wapen wedloop, en in tegenstelling tot bedrijven of publiekelijke onderzoekinstituten hebben deze overheden ongelimiteerde middelen. Snowden leaks liet bijvoorbeeld al zien hoe agressief de NSA & CIA toptalenten rekruteerde van de Amerikaanse universiteiten (MIT, Yale, Standford).

Dus, ik met mijn tin foil hat on, acht het mogelijk dat we eerder 0-10 jaar verwijderd hiervan zijn.
Maar goed kan er ook naast zitten :p
Ik denk eerder dat het veeel langer gaat duren. Kernfusie is ook al 70 jaar lang "over 10 a 20 jaar". En er is nog bijna niks.
Maar de computerwereld is een stuk groter en gaat veel meer geld in rond, dus daar is mee incentive om dit voor elkaar te krijgen.
Je hebt ook Grover's algoritme die bijvoorbeeld AES sneller kan kraken dan momenteel kan. https://en.m.wikipedia.org/wiki/Grover%27s_algorithm
Ja, maar dat is maximaal slechts een kwadratische speedup t.o.v. de exponentiële speedup van Shor's algorithm. In de praktijk betekent dat als je je sleutel een paar bits langer maakt je de speedup al teniet kan doen - i.a.w. eigenlijk geen enkel probleem voor de veiligheid van symmetrische encryptie dus.
Als je nu AES256 gebruikt moet dat inderdaad voldoende zijn. AES128 wankelt wel over 20 jaar, maar zal alsnog veel tijd kosten.
nou het kan snel heel gaan, immers het probleem is qubits te koppelen.
nu nog is 30 qubits koppelen heel knap,.. wat als er straks naar wens 256 of 100.000 qubits gekoppeld gaan worden voor bepaalde zaken wordt dan de rekenkracht ongekend, helaas is decypty daar ook een bepaalde zaak voor.

Maar 10 jaar... dan is het internet ook verouderd, ook bitcoins zijn op z'n end dan geld is waardeloos geworden, daar staat dan tegenover dat die robotjes alles gaan doen voor ons .
Indien je code max een aantal dagen nodig heeft om te ontcijferen en je code max. 1 dag toegang verschaft zit je dus veilig.
Voor mijn qubits machine van gisteren ging dat nog op ja, maar die van vanochtend... ;)
Volgens onderzoekers heb je met voldoende qubits de Shor algoritme niet nodig en kan rechtstreeks de hashing van AES terugspelen. Voor AES 256 zijn ongeveer 6681 qubits nodig.
Wat symmetrische crypto betreft is het ook noemenswaardig dat Diffie-Hellman key exchange kwetsbaar is voor quantum computers (door Shor's algoritme voor het discrete logaritmeprobleem), waardoor die kwadratische speedup door Grover's algoritme ineens niet meer de grootste zorg is.
We worden al een jaar of 5 geadviseerd om ed25519 ipv rsa te gebruiken, bijvoorbeeld voor ssh. Is dat hiermee nu ook een aflopende zaak, of bied het nog meerwaarde?
Kleinere grootte sleutel en handtekening. Soms sneller.
ik gebruik al heel lang ed25519 in plaats van rsa. de verificatie is echt een stuk sneller in vergelijking met een rsa 4096/8192 key. ze generen ook sneller, maar das maar keer
Opvallend dat de NBV (onderdeel van de AIVD) pleit voor hybride constructies. In die constructies is de (asymmetrische) sleuteluitwisseling gebaseerd op zowel 'klassieke' cryptografie als Post-Quantum Cryptography. Naar deze constructies wordt op dit moment onderzoek gedaan en het lijkt er op dat het meest gebruikte versleutelingsprotocol TLS hier ook ondersteuning voor gaat bieden [0].

Toch wijkt dit af van wat de Amerikaanse inlichtingendienst NSA gaat doen [1]. In plaats van tijdelijk gebruik te maken van hybrid systemen als transitie, zullen zij vrij snel overstappen op volledige Post-Quantum Cryptography. De reden daarvoor is dat hybrid systemen meer code vereisen waardoor de kans op implementatiefouten ook groter wordt. In de praktijk zijn het vaak implementatiefouten die voor een kwetsbaarheid zorgen, en niet de algoritmen.

Het is wel goed om te lezen dat de NBV nog even noemt dat Quantum Key Distribution een heilloze exercitie is. Helaas is dat kwartje nog niet bij iedereen gevallen en worden er nog steeds onderzoeksgelden gestoken hierin... ([2][3])

[0] https://datatracker.ietf....etf-tls-hybrid-design/03/
[1] https://twitter.com/mjos_crypto/status/1433443198534361101
[2] nieuws: Twentse onderzoekers ontwikkelen quantumbeveiliging multimodeglasvezels
[3] nieuws: QuTech demonstreert distributie quantumsleutels via centrale node ove...

[Reactie gewijzigd door Darses op 23 juli 2024 06:33]

Zou je (voor een leek) kunnen uitleggen wat Quantum Key Distribution is en waarom het "een heilloze exercitie is"?
Quantum Key Distribution (QKD) maakt gebruik van quantumeigenschappen om gegevens uit te wisselen. Denk aan lasers en glasvezelkabels, alleen dan op zo'n manier dat je de informatie maar 1 keer kan uitlezen. In tegenstelling tot huidige glasvezelkabels kan je dus niet meer de lichtbundel splitsen en deze vervolgens (passief) afluisteren. QKD is dus niet af te luisteren.

Het probleem is dat je gegevens wel vertrouwelijk blijven, maar je geen idee hebt of je data wel bij de juiste partij aankomen (authenticatie). Daardoor kan je een Man-in-the-Middle aanval opzetten, waarbij je als kwaadwillende de gegevens tussen twee partijen doorstuurt. Daar bied QKD geen bescherming tegen. Om daar toch tegen te beschermen heb je, je raad het al, Quantum Key Cryptography (QKC) nodig (of symmetrische cryptografie, zoals ook in de brochure staat). Linksom of rechtsom ontkomen we daar dus niet aan. QKD voegt dus niet zoveel meer toe want we hebben hoe dan ook QKC nodig.

[Reactie gewijzigd door Darses op 23 juli 2024 06:33]

Op enkele na, de meeste blockchains hebben dus echt een mega probleem in de toekomst 8)7
Sja, bouwen op drijfzand. Als je iets langdurig hypersecuur wil bouwen en releasen, moet je de evoluties hierin in de smiezen hebben. Wat niet gebeurt. Zo hebben we weer een typische hype cyclus, alleen draait er wel veel privé geld in rond 😳
Mooi dat de dienst hier al over nadenkt en adviezen over uitbrengt. De groep organisaties waar dit advies voor bedoeld is, is echter wel erg klein. Er zijn maar weinig organisaties, naast de overheid, die data die nu verwerkt wordt nog 20 jaar geheim moeten houden.
Ik als werkzaam iemand binnen de cybersecurity neem dit soort informatie zeker mee in onze cyberstrategie. Genoeg data dat voor langere tijd gebruikt moet worden i.v.m. wet en regelgeving, maar ook als het gaat om back-ups, IP en source code waar cryptografische berekeningen in gemaakt worden.

Persoonlijk denk ik dat het air gappen van data en daarmee datadragers de norm gaat worden. In dat geval heb je in principe slechts met alleen fysieke beveiliging te maken. Veel beter qua beveiliging te beheren dan lokale servers, datacenters en de cloud.
Loskoppelen werkt natuurlijk heel goed tegen hackers via een netwerk/internet, maar hoeveel bedrijven / andere organisaties kunnen zonder internet nog uit de voeten? Wat moet ik me hier in de praktijk bij voorstellen, dat je voor elke query een mailtje stuurt of belt met een helpdesk, waarbij een medewerker je vraag van de ene computer overtypt op de andere? Ik kan me hier nauwelijks zinnige praktijkvoorbeelden bij voorstellen.
Denk bijvoorbeeld aan een sluis. Daarvan zijn de meeste, naar mijn weten, air gapped.
Er zijn ook nog wel wat voorbeelden in de commerciële hoek (en vermoedelijk / hopelijk inlichtingendiensten / opsporingsinstanties), maar dan heb je het echt over bijzonder gevoelige of waardevolle data.

Ander vreemd voorbeeld: paper / hardware wallet voor crypto. Is natuurlijk niet helemaal hetzelfde, maar het idee erachter is vergelijkbaar.
Ik ben niet zo thuis in de scheepvaart, maar begreep dat bijvoorbeeld de Harinvlietbrug vaak onbemand is / op afstand bestuurd wordt. Dat kan dan toch niet airgapped zijn? Daarnaast lijkt me dat nou niet iets waar gevoelige informatie mee gemoeid is. Natuurlijk is het niet de bedoeling dat iemand met die brug gaat lopen kloten maar om nou te zeggen dat het een systeem is wat een top cryptografische versleuteling nodig heeft…
Waar ik op doel zijn de sluizen voor de waterkering. Als die op het verkeerde moment niet werken is de schade immens. In mensenlevens en schade. Als je dat niet belangrijk vindt dat zal je van geen enkele hack onder de indruk zijn ;).

Ik weet niet hoe het met bruggen zit, dat is inderdaad wat minder spannend.
Ik weet niet hoe het met bruggen zit, dat is inderdaad wat minder spannend.
Nou in combinatie met die waterkeringen wel spannend, want je zou er dan immers voor kunnen zorgen dat de bruggen opengaan, zodat er niemand kan ontsnappen. Dat maakt de impact dan nog groter
Ik ga er van uit dat dit soort kunstwerken altijd nog een lokale, handmatige bediening heeft.

Juist bij calamiteiten waar ze voor zijn ontworpen heb je immers geen garantie dat netwerkverbindingen actief blijven. Sowieso zijn de Deltawerken pre-internet gebouwd.

Overigens kan een watersnoodramp zoals vorige eeuw plaatsvond nu niet meer gebeuren. Daarvoor liggen er te veel dammen in de weg en zijn de buitendijken te veel versterkt en verhoogd.
cc @Elp
De fysieke beveiliging is ook niet te onderschatten, als het om echt gevoelige data gaat, met van Eck phreaking is al diverse keren covert communicatie met air-gapped systemen gerealiseerd door onderzoekers. Nb, je zal ook heel goed moeten kijken hoeveel EM je systemen weglekken naar "buiten", en hoe.
Er zijn maar weinig organisaties, naast de overheid, die data die nu verwerkt wordt nog 20 jaar geheim moeten houden.
Allereerst: ik ben het niet eens met de claim dat er niet zoveel data is die 20 jaar geheim moet blijven. Alle data die je nu wil versleutelen wil je versleutelen omdat je niet wil dat iemand anders de inhoud kent. Nu niet en later niet. Denk bijvoorbeeld aan medische data, GGZ data en alles wat je verder liever privé houdt. (boek tip: "Je hebt wél iets te verbergen" door Maurits Martijn, als je een beter beeld wil krijgen van wat je allemaal, bij nader inzien, liever voor je zelf wil houden).

Maar belangrijker is dat de AIVD nu juist waarschuwt voor het risico dat die 20 jaar wel eens veel korter zou kunnen blijken omdat de ontwikkelingen sneller gaan.
Die 20 jaar is niet zozeer een houdbaarheidsdatum, maar geeft een idee wanneer het betaalbaar is geworden om huidige cryptografie te ontsleutelen. "Nu zou je nog zoveel rekenkracht in moeten kopen dat het wel héél duur is om data te achterhalen, maar over 20 jaar is makkelijk betaalbaar" is nu de reden om bepaalde algoritmes te gebruiken. De AIVD stelt, als ik het artikel tenminste goed begrepen heb, dat versleutelde data over 10 jaar misschien al betaalbaar te ontsleutelen is. Of over 5 jaar, niemand die het weet. En dan wordt het heel anders natuurlijk.
Daarom vertrouwt Apple bijvoorbeeld geen TLS certificaten met een geldigheid van meer dan een jaar meer. En is er een concept als "Perfect Forward Secrecy" (een techniek die er, simpel gezegd, voor zorgt dat slechts een heel korte periode van versleutelde communicatie met een bepaalde sleutel kan worden ontsleuteld. Hierdoor moet je veel meer sleutels ontsleutelen en wordt het duurder, neemt de houdbaarheid van versleuteling toe.
Aan Aswen

Je zegt "Allereerst: ik ben het niet eens met de claim dat er niet zoveel data is die 20 jaar geheim moet blijven".

Dit is een buitengewoon belangrijke opmerking.

Er is een data/privacycrisis aan de gang, niet zo lang geleden begonnen, die net zo groot zal worden als de klimaatcrisis. Ik blijf er op hameren, ik zie alle verschijnselen en ik heb dit al vele jaren voorspeld.

Jouw opmerking is een extra gegeven (naast alle andere) dat bewijst dat die crisis echt bezig is. Als alle zaken die nu beveiligd moeten worden, over 10-20 jaar compleet op straat liggen, is werkelijk iedereen beschadigd. Elk mens, elk bedrijf, elke politieke groep enzovoort.

De combinatie "nu aftappen en bewaren, en over 10-20 jaar ontcijferen" is heel reëel. Het is doodsimpel en het is dus geen science fiction. Opslag is spotgoedkoop. Daardoor kun je erop rekenen dat dit ook echt gebeurt - dat wil zeggen dat er landen, instituten of personen zijn die dit daadwerkelijk doen. Er worden véél moeilijker trucs uitgehaald om gegevens te bemachtigen, dus dit proces van data opslaan om later te decoderen, is beslist iets wat gebeurt.
Denk bijvoorbeeld aan medische data, GGZ data en alles wat je verder liever privé houdt.
Mee eens, maar dan moet er iemand al wel pro actief mijn data nu al op gaan slaan met de wens omdat in de toekomst te ontsleutelen. Dat is het met name het argument om het nu al te implementeren.

Nu ben ik best paranoia, maar als iemand mijn gezondheidsgegevens nu al wil hebben, dan zijn daar al genoeg mogelijkheden voor. Het hacken van een gemiddeld ziekenhuis is geen rocket science.
Het is een probleem overal waar je met keymateriaal met een lange levenscyclus werkt.

Bij $dayjob is het relevant en verwachten we dat we er komend jaar nog niet aan kunnen denken (ecosysteem te jong) maar binnen vijf jaar wel.
Wat ik mis in het artikel is hoe lang het duurt om met een quantum computer een code te "kraken". Stel dat zo'n systeem een huidige code kan oplossen in 1 jaar in plaats van een paar honderd jaar, dan zou voor mij dat niet echt een probleem zijn. In een jaar is waarschijnlijk 99% van mijn opgeslagen informatie nutteloos geworden, of het wachtwoord is gewijzigd. De 1 procent is eenvoudig te beveiligen met een printer en een kast die op slot kan. Als het een dag of zo duurt om een code te kraken zou ik me wel zorgen maken.

Kan me voorstellen dat voor bedrijven en overheden het anders ligt.
Waar ze dus ook voor waarschuwen is dat allerlei data die NU versleuteld wordt verstuurd of versleuteld is door iemand wordt opgeslagen om later als de mogelijkheid daar is te ontsleutelen. Beetje hetzelfde idee als mensen die ziek zijn die zich laten invriezen in de hoop dat ze in de toekomst 1) mensen kunnen ontdooien en 2) een medicijn hebben
De 1 procent is eenvoudig te beveiligen met een printer en een kast die op slot kan.
Jij gebruikt internetbankieren door het uit te printen? En dan, stuur je het dan op via een brief, zoals 20 jaar geleden? :P Het is natuurlijk niet alleen om lokaal opgeslagen informatie. Juist alles wat je over het internet gooit is nogal een probleem als dat zo ingezien kan worden. "Het groene slotje" bij het inloggen bij je bank, je mail-server en je belastingaangifte is allemaal symmetrische crypto, hé.

En nee, dit gaat niet om een factor honderd. Dit gaat om exponentiele versnelling. Als een quantumcomputer zo bruikbaar en schaalbaar zou zijn als de huidige klassieke CPU kun je bij wijze van spreken real-time meekijken in een versleutelde verbinding (al zal dat zo'n vaart niet lopen omdat quantumcomputers nogal wat lastiger te produceren en te gebruiken zijn).

[Reactie gewijzigd door bwerg op 23 juli 2024 06:33]

Mijn "betoog" was dat gekraakte informatie van nut moet zoet, dan wel relevant. Als het 1 jaar duurt om een wachtwoord te kraken is die al veranderd gedurende dat jaar. Dus dan komen ze er nog niet in. Als het 10 seconden zou duren, is het een ander verhaal.

Als het een jaar duurt om een gecodeerd zip bestand te kraken, is de informatie in dat zip bestand al 1 jaar oud. Grote kans dat het dan niet meer relevant is.

Echt belangrijke informatie heb ik (ook) op papier. Zoals een adresboekje zodat ik altijd het telefoonnummer weet van iemand, als de computer kuren heeft. Of een lijstje met wachtwoorden.

Tja, als het groene slotje van de bank gekraakt wordt is dat vervelend. Ze kunnen dan inzien dat ik een pak melk kocht bij de lokale super maar nog geen geld overboeken. Daarvoor is een aparte autorisatie code nodig die elke X seconden veranderd.

Begrijp dat het voor bedrijven en overheden anders kan zijn. Je zou maar net een mooie uitvinding hebben opgeslagen in de cloud en die wordt gekraakt. Daar gaan je inkomsten.
Je zegt 'als het 1 jaar duurt om iets te kraken'. Maar je weet toch zelf ook wel dat het dan niet lang zal duren voordat het in een half jaar, of 3 maanden of nog veel korter zal kunnen? Dat kan door betere hardware, maar ook door betere algoritmes.
Je hebt dus echt een hoge marge nodig, iets van miljoenen jaren.
Kijk b.v. naar RSA-129, een getal dat in 1977 gepubliceerd werd met de uitdaging om het in factoren te ontbinden. Dit was gedaan om de betrouwbaarheid van RSA te promoten.
Volgens de bedenkers van RSA zou het miljoenen jaren duren voordat dit gekraakt zou kunnen zijn. Maar in 2003 was het al zover.
We zijn er ook niet ver verwijderd van meer dat Quantum niet een jaar meer nodig heeft maar wellicht maar een week.

Verschil tussen quantum en traditionele PC's / GPU's etc is dat Quantum alle 10 deuren tegelijk opent zoekend naar het object achter de deur, en de PC hedendaags deur voor deur afgaat.
Crystal van IBM maakt gebruik van roostercryptografie. Dit algoritme versleutelt informatie met behulp van een wiskundig probleem waarvan niet bewezen is dat quantumcomputers het niet kunnen oplossen, maar waarvoor geen enkele aanwijzing bestaat dat ze het kunnen oplossen.
IBM is natuurlijk niet de enige. Google en Cloudflare zijn hier ook al langer mee aan het experimenteren en NIST is al een hele tijd bezig met het standardaardiseren van post-quantum cryptografie.
https://pq-crystals.org is niet van IBM, het is van een groep losse onderzoekers van voornamelijk universiteiten en onderzoeksinstellingen, waaronder CWI en de Radboud Universiteit in Nijmegen.
tsja, de kracht van de blimsem oogsten en hier zelf licht mee maken was 200 jaar geleden ook ondenkbaar/onmogelijk en was geen enkele aanwijzing hoe wij mensen dat varkentje zouden wassen.

Kijk naar de ontwikkeling van de laatste 20 jaar omtrent gloeilamp -> fluoresent (TL/spaar) -> LED
Ik gebruik altijd een custom dynamische rommelmaker vóór ik er nog eens een "standaard" encryptie (bcrypt) overheen gooi. In al mijn producten sla ik werkelijk nergens het plain-text wachtwoord op. Wachtwoord vergeten = pech, dan moet je een nieuwe aanvragen.

Die dynamische rommelmaker is vast en zeker snel uitgevogeld door toekomstige AI (Ik map bepaalde characters aan bepaalde waardes, die worden dan weer berekend om óf te veranderen in andere karakters of karakters in te voegen, afhankelijk van de datum, en nog een paar van dat soort geintjes). Het wachtwoord "wachtwoord" kan dus zomaar opeens uitkomen op "wj890fhdoi~y" maar bij een andere gebruiker weer als iets totaal anders. Mochten ze de bcrypt decrypten, zijn de wachtwoorden, access tokens enz alsnog een "jumbled mess". Helaas is dit natuurlijk niet toepasbaar voor data welke nog wél decrypted moet kunnen worden om daadwerkelijk te lezen. Maar hierbij zal het altijd een race zijn tegen de klok lijkt me, quantum of niet?

Desondanks lijkt het mij dat wij hier toch compleet afhankelijk gaan zijn van hoe snel en hoe slim AI en quantum computing optrekt. Uiteindelijk ligt een sterke encryptie toch bij de tools welke je tot je beschikking hebt... toch?

Het beste blijft toch vooral het voorkomen van toegang tot de data in kwestie (welke alsnog encrypted moet zijn natuurlijk) lijkt me. Ik neem aan dat de decryption snelheid van quantum computing nog steeds niet betekent dat ze een IP-whitelist voorbij kunnen komen?

Tevens doet mij dit denken; Hoeveel hiervan ligt buiten onze handen? Denk hierbij bijvoorbeeld aan het HTTPS protocol. Zou deze ook 'snel genoeg' decrypted kunnen worden met quantum computers? En zijn wij dan weer afhankelijk van andere quantum computers om het kat en muis spelletje weer opnieuw te starten?
Ik weet niet waar ik moet beginnen hiermee dus ik reageer maar gewoon op https.

Https is zelf niet iets wat een quantum computer breekt. Het betekent gewoon dat het http is dat versleuteld is. Die versleuteling is tegenwoordig foor TLS, maar dat betekent nog niet dat TLS het doelwit is. Je gebruikt een encryptie voor TLS, vaak RSA, elliptic curve of diffie hellman. Als je het daarover hebt dan ja, quantum computers kunnen die breken. Maar https is niet iets wat je breekt, want https beschrijft het encryptiealgoritme niet.
Bedoel je met 'custom dynamische rommelmaker' een hash + salt, zo ja dan hoop ik dat je het algoritme erachter niet zelf in elkaar hebt geflanst.

En anders zou ik maar overstappen naar de bcrypt hashing algorithm aangezien je toch al bcrypt gebruikt voor encryption.
Dat heb ik wel, maar volgens mij geef ik vrij duidelijk aan dat ik er óók nog bcrypt overheen gooi. Dat ik wat extra (custom) stappen neem betekent niet dat ik me niet aan de standaarden hou. Deze misconceptie zal wel weer eens de reden zijn van downvotes. Niemand zo hard downvotend als programmeurs die het niet oké vinden dat sommige programmeurs nog zelf dingen maken en doen.

"Waarom zou je zelf een library maken als er al 10 bestaan?"
"Waarom zou je zelf extra veiligheidsmaatregelen nemen als je gewoon deze ene enkele default kan gebruiken?"
"Waarom zou je zelf nog css schrijven als je gewoon bootstrap kunt gebruiken?"
"Waarom zou je nog een custom CMS maken als Wordpress bestaat?"

Vermoeiend. Alsof al die dingen zouden bestaan en blijven doorontwikkelen wanneer programmeurs stoppen dat soort dingen te doen. Misselijkmakende "waarom het wiel opnieuw uitvinden?" houdingen, terwijl als we dat niet deden, we nog op stenen blokken rond zouden rijden. Intussen krijg ik een berg off-topic/irrelevant votes (en zelfs ongewenst) terwijl ik het toch echt over het onderwerp in kwestie heb.

Sterker nog, als het zo mag zijn dat iemand quantum computing gaat gebruiken om alle standaard encrypting tools tegen te gaan, is die custom "zelf in elkaar geflanste" zooi je allerlaatste verdediging. Sinds wanneer is het opeens slim om maar één beveiligingsmaatregel te nemen ipv meerdere?
Het komt vaker wel dan niet voor dat je met je "zelf in elkaar geflanste allerlaatste verdediging" onbedoeld juist meer informatie prijsgeeft dan je zou willen en wellicht het uiteindelijke kraken makkelijker maakt, in plaats van moeilijker. Het is leuk dat je programmeur bent maar crypto is meer iets wiskundigs en daar ontbreekt bij jou gewoon de kennis die nodig is om iets te maken wat veilig en robuust is. Dat zeg ik met overtuiging doordat je zegt zelf iets gemaakt te hebben, wat iemand met voldoende kennis van zaken niet zou doen omdat diegene weet dat het ongelofelijk complexe materie is met enorm veel valkuilen. Rijndael is ook niet in een middagje in elkaar geknutseld, daar heeft heel veel onderzoek in gezeten en het heeft bovendien zichzelf moeten bewijzen tegen een flink aantal andere encryptie-algoritmen voordat het zichzelf AES mocht noemen.

Je mag dit natuurlijk zelf doen maar je moet je zeker bewust zijn van alle risico's die dat met zich meebrengt. Om nog maar te zwijgen over dat je benadrukt dat het "custom" en een "allerlaatste verdediging" is, die "uitgevogeld" moet worden voordat iemand ermee kan, dat klinkt namelijk enorm als security through obscurity. Dat is valide******** maar mag zeker nooit de enige peiler van security zijn in je algoritme. Als je algoritme fatsoenlijk is kan je die nu hier openbaar maken zonder dat dat iets afdoet aan de veiligheid ervan. Dus ik ben benieuwd.

[Reactie gewijzigd door DataGhost op 23 juli 2024 06:33]

Ten eerste; Nee ik kan mijn algoritme niet zomaar openbaar maken, want dan kan hij reverse engineered worden dus dat is dom. Zoals je zelf zegt is het security through obscurity.

Ten tweede: Zoals ik nu al voor de 3e keer aangeef (oh mijn god, zijn jullie oost-indisch blind ofzo?) doe ik dit allemaal vóór ik er gewoon normale, moderne standaarden aan crypto overheen gooi. Welke ik dus wel degelijk gebruik. Zoals nu al voor de 3e keer aangegeven. Echt ongelofelijk dit. Zoals ik al aangaf, is het iets wat ik doe als EXTRA maatregel, niet als ENIGE maatregel. Wat is er mis met jullie?

Edit: even voor clarity: Het is mij aangeleerd dit te doen omdat er wel eens fouten zijn gemaakt zoals het falen van andere cryptografie, waarna vrijwel alles dus uit te lezen was. Op het moment dat een crypto gekraakt is wordt het gewoon met bots op iedere plek waar het kan gekraakt. Een custom salt is op dat moment wel degelijk je laatste defense line.

[Reactie gewijzigd door NoobishPro op 23 juli 2024 06:33]

Ik denk dat een goede search & replace meerdere keren uitvoeren een wiskundige gaat zeggen dat is geen wiskunde maar dan wel tegen z'n leidinggevende waar het decrypt dient te worden en dus als encrypted wordt bestempeld. Niet te ontcijferen...
Wat ik dus probeer aan te geven, is dat je met je "extra" maatregel onder andere de ingevoerde data zodanig kan transformeren dat er door het gebruik van jouw algoritme enige informatie uitlekt of het geheel makkelijker te kraken wordt, ondanks het gebruik van gangbare encryptie erbovenop. Het is bijvoorbeeld behoorlijk waarschijnlijk dat je op jouw algoritme tig side-channel attacks kan doen waardoor je de echte encryptie die erbovenop zit niet eens hoeft te kraken, dat doet jouw systeem namelijk wel voor de aanvaller. Dus extra is niet altijd beter, in het geval van zelfbouw door iemand zonder gedegen achtergrond in cryptografie vaak juist slechter.

En als je algoritme niet openbaar gemaakt kan worden maak je dus hoogstwaarschijnlijk geen gebruik van een key, of is je key door een buitenstaander te berekenen of af te leiden. Inderdaad doodzonden.

Het "falen van andere cryptografie" is, zolang er geen aanvallen op het algoritme zelf bekend worden, in vrijwel 100% van de gevallen te wijten aan de uiteindelijke implementatie door... vaak een programmeur (of nog niet eens) zonder achtergrond of interesse in crypto. Het enige wat jij introduceert is een extra laag waarin dit nogmaals mis kan gaan. Maar je moet het zelf weten. Ga het alleen niet als best practice promoten, want dit is bijna het tegenovergestelde.
Wat je zegt klopt gewoon finaal niet.

Er is geen enkele "in" bij wat ik doe. Er is geen enkele vorm van invloed op uit te oefenen. De reden dat ik mijn formules niet deel is simpelweg omdat het security through obscurity is, zoals de meeste dingen. Als ik hem deel kun je inderdaad nog steeds niet zomaar de data uitlezen, maar het geeft je wel een betere indiciatie van hoe je kunt zoeken naar de key / een sterkere kans de resultaten te reverse-engineeren omdat je weet wat de formule met de data zou kunnen doen afhankelijk van hoe de key er ong uit zou zien, en zo op zoek gaan naar de key.

Mijn implementatie gaat zeer zeker niets van doen hebben met "het falen van cryptografie". Ik weet dat het een slecht voorbeeld is, maar neem b.v. MD5 encryptie. Dat is al erg lang volledig decrypted. In de tijd dat het volledig decrypted was, was het echter nog steeds de standaard van CMSen als Magento en Wordpress en werd het dus nog enorm veel gebruikt.

Als mijn custom truucje zorgt dat ze deze MD5 decrypten, en als string "G4309@!~d" terug krijgen i.p.v. het wachtwoord "henkiespenk", heb ik dus een extra beveiligingslaag toegevoegd.

En ja, als je het mij vraagt is dat wel degelijk best practice. Want je hebt gewoon geen idee wanneer de gebruikte encryptie gaat falen (hoewel deze toegegeven, aanzienlijk beter zijn geworden in de laatste jaren, vooral mbt web)

Dat verandert echter nog steeds echt 0,0 dat ik absoluut 0 extra risico implementeer met mijn rommelmakertje. Het is gewoon een laagje obscurity en dat is een manier van beveiliging welke werkelijk overal gebruikt wordt. Ik zou zelfs durven zeggen dat veruit de meeste 'standaard security' (vooral in web) security through obscurity is.

Voor je het weet ga jij mij nog een idioot noemen omdat ik altijd alle FTP accounts van mijn productie omgevingen verwijder na gebruik of wat voor een idioot ik ben dat ik default alle read & write rechten disable op de codefolders. Want "mensen komen toch niet in de FTP, dus waarom zou je die rechten niet gewoon laten staan?"

Het feit is, dat WIJ als gebruikers ons totaal niet bewust zijn van onze eigen ONveiligheid. Jij zegt " zolang er geen aanvallen op het algoritme zelf bekend worden" en ik zeg "Je kunt beter wat meer beveiliging hebben, want je weet niet wat er nog NIET bekend is"
Zoals ik in een andere reactie al aangaf, je hebt zelf geen flauw idee van de terminologie dus je zegt van alles wat eigenlijk nergens op slaat, terwijl het volkomen onduidelijk blijft wat je precies doet. Dat maakt het erg lastig om erover te discussiëren.

MD5 is geen encryptie, het is een hashfunctie. MD5 is ook niet decrypted, het is slechts makkelijk geworden om collisions te berekenen. Het is per definitie onmogelijk om te achterhalen wat de originele invoer was als je alleen de resulterende MD5-hash hebt, en dat zal zo blijven tot het einde der tijden, zelfs met quantum of weet ik veel wat voor interdimensionale warp-computing we over 2 miljoen jaar hebben. Waarom dit zo is laat ik over als oefening aan de lezer.

Als jij dus iets doet als X -> [jouwding] -> Y -> MD5 -> Z, en Z is bekend, kan er waarschijnlijk een Y berekend worden die Z oplevert. Als het zo belangrijk is om jouw algoritme geheim te houden, is het waarschijnlijk triviaal om een bepaalde X te fabriceren die Y oplevert. Effectief heb je dan uiteindelijk weinig tot niks bijgedragen aan de veiligheid, maar dat zal jij anders zien. Als ik het zo een beetje lees, denk ik dat jij denkt dat je een hash-functie gemaakt hebt, hoewel het in de praktijk symmetrische encryptie is (en je het ook per ongeluk zo noemt, dus chapeau). Voor het beoogde doel (hashing) is dat dus compleet onwenselijk. Je houdt het nu ook met alle macht geheim en de enige manier waarop dat enige kans van slagen heeft is als je een volkomen oninteressant doelwit bent, maar dat betekent op geen enkele manier dat er geen aanvallen op kunnen en zullen plaatsvinden.

Maar stel nou dat wat je gemaakt hebt wel degelijk een hashfunctie is, en je hebt daar een (denk/ontwerp/programmeer) fout in gemaakt waardoor er onbedoeld alleen maar de uitkomsten "G4309@!~d" en "wj890fhdoi~y" uit kunnen komen, ongeacht de invoer. Jij hebt het getest met twee verschillende invoeren en beide keren "random" uitvoer gezien, dus alles prima toch? Totdat zowel "supermoeilijkwachtwoord132874blablaDitWordtNooitGekraakt", "correct horse battery staple" en "123" dezelfde uitkomst "G4309@!~d" hebben. Dat voer je vervolgens aan MD5 of bcrypt of wat dan ook, en daar komt dan even hard dezelfde uitkomst uit. Je hele database staat nu vol met users die allemaal dezelfde wachtwoord-hash hebben, terwijl ze allemaal denken een uniek wachtwoord te gebruiken. Is dan de veiligheid verbeterd omdat jouw obscure algoritme ertussen zit, vind je?

Dat je zo hard claimt dat je 0 extra risico implementeert (en de rest van de alinea ook) geeft al aan dat je niet geschikt bent om daar een oordeel over te vellen. Dat kan niemand, terwijl het omgekeerde hoogst aannemelijk is.

Over je FTP-alinea, geen idee, ga ik geen oordeel over vellen behalve dat FTP een onversleuteld protocol is waar al decennia lang versleutelde alternatieven voor bestaan en gemeengoed zijn. Als je dat nu nog steeds gebruikt noem ik je om die reden een idioot ja. En wat betreft het wijzigen van de permissies op mappen, dat kan verstandig zijn ja. Maar als je als user X inlogt op FTP en als diezelfde user X de rechten op bepaalde mappen kan intrekken of toekennen, heeft het natuurlijk geen zin om dat te doen als je je probeert te wapenen tegen de situatie dat iemand met user X in weet te loggen op die FTP. Ik bedoel, de enige die je daarmee tegenhoudt is iemand die nog nooit met FTP gewerkt heeft, en dat is niet iemand die onbedoeld op jouw FTP binnenkomt.
Jij zegt " zolang er geen aanvallen op het algoritme zelf bekend worden" en ik zeg "Je kunt beter wat meer beveiliging hebben, want je weet niet wat er nog NIET bekend is"
Dat zeg ik, met de context van jouw stelling "falen van andere cryptografie", welke in het overgrote deel van de gevallen niet te wijten is aan de gebruikte encryptie/hashing-methode maar aan degene die ze gebruikt. Dus voor die personen gaan extra obscure laagjes ook niet werken, en als zulke personen zelf hun obscure laagjes gaan maken kan het alleen maar erger worden.
Ik denk niet dat wij het per sé oneens zijn met elkaar, maar we het een klein beetje over andere dingen hebben.
Jij hebt het voornamelijk over cryptografie en hashes. Ik heb het denk ik meer over obscurity maatregelen, mochten deze ergens falen. Daarnaast focus ik vooral op web en specifiek wachtwoorden. Jij zit wat globaler denk ik. Tevens is 2FA natuurlijk ook een super sterke maatregel mbt login-security.

Ik geloof ook niet dat obscure extra laagjes super betrouwbaar werken tegen hackers, maar wel tegen crawlers/bots. In het geval van bots hoeft dit vaak niet complex te zijn. Enkel 'afwijkend'.
Veruit de meeste grote hacks worden uitgevoerd door bots d.m.v. de bekendheid van de codebase (in web iig). Een hacker vindt een foutje/lek, schrijft een bot om te crawlen et voila, een mass hack. Hiervan zijn open-source of welbekende platforms dan ook vaak het slachtoffer (wordpress, laravel, magento, enz) Het obscuur maken van dingen betekent hier basically gewoon afwijken van de norm zodat de meest generale bots al meteen niet meer binnen komen. Zo kon ik met een klein custom scriptje in Wordpress proppen dus al enorm veel bot-hacks voorkomen (note; ik praat hier over vrij lang geleden), dmv obscurity. Wederom; Niets complex, geen cryptografie. Gewoon obscurity. Voor overige (echte) hacks wordt je natuurlijk targeted en dan ga je over hele andere beveiligingsmaatregelen spreken.

Tevens klopt wat jij in het begin zegt ook niet. Er is absoluut geen enkele mogelijke manier waarop mijn algoritme een dubbel resultaat kan krijgen. Daar heb ik rekening mee gehouden met het bouwen. Het is geen complex genoeg algoritme om zo complex te zijn als cryptografie. Het is een simpele salt hash welke gebruik maakt van enkele dynamische data-points en een dynamische key. Deze hoeft niet over-complex hoeft te zijn omdat ik (nogmaals) daarna vervolgens gewoon de standaard beveiligingen implementeer. Er is verder geen hook, waarmee iemand in deze laag kan komen.

Dus, mocht er weer zoiets gebeuren als bij MD5 (dus collisions berekenen b.v.), krijgt iemand een string terug zoals b.v. "49039~2GF" i.p.v. "mijnwachwtoord" en daar kunnen ze absoluut niets mee, tot ze de formule + key kraken welke ik heb gebruikt om deze te maken.

En waar jij stelt dat deze "dubbele waarde" een probleem zou kunnen vormen, zelfs als het wél mogelijk zou zijn, zou het nog steeds geen enkel probleem zijn. Want deze waarde, dubbel of niet, zou nergens gebruikt kunnen worden. Alsin; deze kun je nergens invoeren. Want iedere invoer verwacht een waarde zonder zout.

Ik geef toe dat mijn terminologie niet zo sterk is. Dit is voornamelijk omdat ik het zo min mogelijk gebruik en dus al jaren niet meer bij ben blijven houden hoe ze wat nou precies noemen. Dit voornamelijk omdat er nogal eens discussie is geweest over terminologie en ik daar geen behoefte meer aan had. Een goed voorbeeld hiervan is hoe jij b.v. benoemt hoe er al "decennia lang" alternatieven zijn voor b.v. FTP. Ik blijf het gewoon FTP noemen omdat het in de kern altijd, nog steeds een file transfer protocol is, of daar uiteindelijk op terugvalt. Je kunt het wrappen in 1593932409 lagen en dan de naam veranderen naar 'moving containers' of 'deployment' of allerlei van dat soort prachtige termen, maar puntje bij paaltje is het nog steeds allemaal FTP, enkel met wat extra tussenstappen. Net als hoe ze nu alles "in the cloud" noemen, zoals "software in the cloud" terwijl het gewoon remote desktop is of een browser-applicatie. De eeuwige discussie over scrum (en vervolgens het ontwikkelen van 4393 soorten scrum) is ook een goed voorbeeld van waarom ik niet graag teveel blijf hangen op terminologie.

Wel wil ik stellen dat jij (en anderen) vol zit met aannames. Zoals o.a. je aanname dat ik iets zou testen met "2 strings" ipv b.v. een string generator te bouwen en meer dan 10 miljoen strings door het ding te jassen precies om het punt wat jij maakt te voorkomen.
De aanname dat het weten gebruiken van de exact juiste terminologie iets betekent over de kwaliteit van wat je maakt.
De aanname dat ik maar één persoon ben die er aan werkt.
De aanname dat één persoon nooit iets zo complex zou kunnen maken als iets wat op github staat.

Zo heb ik b.v. ooit een plugin gemaakt (een WYSIWYG editor), waar een aantal mensen enorm fan van waren, om vervolgens kritiek te krijgen dat ik in één project enkele aanpassingen had gemaakt in plugin, want "waarom denk jij dat jij het beter weet dan het hele team wat deze plugin heeft gemaakt en de community? Voer gewoon een change request in!". Uiteraard wist deze persoon niet dat ik de originele maker was van deze plugin, welke al niet meer werd bijgehouden aangezien het bedrijf waarvoor ik deze had gemaakt niet meer bestond. Weer zo'n aanname. Alles meteen afschrijven als slecht omdat het niet iets is wat 'de gemiddelde dev doet'.

Even voor de duidelijkheid; Ik ben zeer zeker geen cryptograaf en weet vrij weinig over cryptografie. Maar ik weet meer dan genoeg over websecurity dat mijn producten nog nooit met hacks te maken hebben gehad. Ik weet ook dat ik niet alles weet en daarom huur ik white-hats in om lekken in mijn producten te vinden i.p.v. dit zelf te doen.
Wanneer ik in samenwerking met deze white-hats al jaren lang zorg dat ik de veiligheid van mijn producten op orde hou, en hiervan leer, mag ik toch wel aannemen dat ik intussen weet hoe ik e.e.a. moet securen, ja. Ik weet echter ook dat hackers vrijwel altijd een voorsprong zullen hebben op ons ontwikkelaars. En om die reden zeg ik; Ja, een SIMPEL stukje custom security though obscurity, is geen slecht iets.
Het doornemen van deze custom stukjes security met collega's (of als je ze kunt betalen, white-hats) is dan wel weer aangeraden ja. Ik kan niet ontkennen dat ik wel eens custom measures heb gezien die inderdaad zo lek zijn als een mandje en juist gaten creëeren. Om die reden kan ik je ook geen ongelijk geven, maar de aanname-grens ligt weer eens laag.
Tevens klopt wat jij in het begin zegt ook niet. Er is absoluut geen enkele mogelijke manier waarop mijn algoritme een dubbel resultaat kan krijgen. Daar heb ik rekening mee gehouden met het bouwen. Het is geen complex genoeg algoritme om zo complex te zijn als cryptografie.
Dan is het dus een soort symmetrische encryptie, ongeacht de complexiteit of effectiviteit. ROT13 is dat ook, ondanks dat het triviaal te herkennen en "kraken" is. Het achterstevoren zetten van de invoer is dat ook. Als er geen dubbele resultaten mogelijk zijn en tegelijkertijd dezelfde input met dezelfde key dezelfde output oplevert, moet dat betekenen dat er ook geen enkele informatie verloren gaat in je transformatie-stap, zodat je met zekerheid kan zeggen dat verschillende outputs ook verschillende inputs moeten hebben. Daarmee is het ook triviaal reversibel, iets wat je compleet niet wilt als je met hashing bezig bent (waar het nog steeds op lijkt). En dat hangt dan nog volledig af van hoe je het hebt ontworpen en of je daar geen fouten in hebt gemaakt.
Het is een simpele salt hash
Dat is het dus per definitie niet gelet op je bovenstaand gequotete uitspraak.
Er is verder geen hook, waarmee iemand in deze laag kan komen.
Die hoeft er ook niet per se te zijn om toch informatie uit te laten lekken.
Dus, mocht er weer zoiets gebeuren als bij MD5 (dus collisions berekenen b.v.), krijgt iemand een string terug zoals b.v. "49039~2GF" i.p.v. "mijnwachwtoord" en daar kunnen ze absoluut niets mee, tot ze de formule + key kraken welke ik heb gebruikt om deze te maken.
Wat nou als ik "abcdef" invoer en kijk wat voor hash eruit komt, en daar een collision op bereken? En dat vervolgens een paar keer voor "abcdeg" en "abcdeh" ofzo? Dan kan je daarmee jouw algoritme en key berekenen.
En waar jij stelt dat deze "dubbele waarde" een probleem zou kunnen vormen, zelfs als het wél mogelijk zou zijn, zou het nog steeds geen enkel probleem zijn. Want deze waarde, dubbel of niet, zou nergens gebruikt kunnen worden. Alsin; deze kun je nergens invoeren. Want iedere invoer verwacht een waarde zonder zout.
Als er een dubbele waarde is die uiteindelijk dus dezelfde hash oplevert na al je transformatie-stappen, betekent dat bijvoorbeeld dat een bepaalde user met twee verschillende wachtwoorden in kan loggen. De benodigde tijd om het geheel te kraken is daarmee een stuk korter geworden.
Ik geef toe dat mijn terminologie niet zo sterk is. Dit is voornamelijk omdat ik het zo min mogelijk gebruik en dus al jaren niet meer bij ben blijven houden hoe ze wat nou precies noemen. Dit voornamelijk omdat er nogal eens discussie is geweest over terminologie en ik daar geen behoefte meer aan had.
Die discussie vindt voornamelijk plaats bij mensen die zich niet interesseren in de juiste terminologie, of gewoon geen kennis van zaken hebben. Kennis halen uit actiefilms en matige journalistiek schaar ik onder beide van deze. De terminologie is sinds introductie niet veranderd. Er is een hele wereld van verschil tussen encryptie en hashing en beide termen zijn ontzettend makkelijk uit elkaar te houden. Dat je dat nog steeds niet doet duidt m.i. gewoon op desinteresse en zeker in een discussie niet handig.
Ik blijf het gewoon FTP noemen omdat het in de kern altijd, nog steeds een file transfer protocol is, of daar uiteindelijk op terugvalt. Je kunt het wrappen in 1593932409 lagen en dan de naam veranderen naar 'moving containers' of 'deployment' of allerlei van dat soort prachtige termen, maar puntje bij paaltje is het nog steeds allemaal FTP, enkel met wat extra tussenstappen.
Nee. FTP is een file transfer protocol, ja. Maar een file transfer protocol is niet FTP. SCP, SFTP en Rsync zijn bijvoorbeeld losstaande protocollen, wezenlijk verschillend van elkaar en van FTP, en wrappen FTP op geen enkele manier. FTPS doet dat dan weer wel, maar volgens mij is dat geen geweldig populair protocol.
Wel wil ik stellen dat jij (en anderen) vol zit met aannames. Zoals o.a. je aanname dat ik iets zou testen met "2 strings" ipv b.v. een string generator te bouwen en meer dan 10 miljoen strings door het ding te jassen precies om het punt wat jij maakt te voorkomen.
Je doet nu zelf allerlei aannames. Mijn punt over "2 strings" was dat je je claims waarschijnlijk getest hebt met X strings (bijvoorbeeld 10 miljoen, maar dat waag ik nog te betwijfelen, ik denk dat 2 dichterbij de waarheid zit), in plaats van dat je je claims wiskundig hebt bewezen waarna testen slechts een formaliteit is om te controleren dat je implementatie de regels van je ontwerp volgt.
De aanname dat het weten gebruiken van de exact juiste terminologie iets betekent over de kwaliteit van wat je maakt.
Nee, inderdaad. Maar het geeft wel ongelofelijk sterke aanwijzingen. Sterker nog: met jouw gebruik van terminologie lijkt het me schier onmogelijk om op een juiste manier studie te doen naar hetgeen waar je mee bezig bent, en daarmee impliceert dat dat zoiets ook nooit gebeurd is. Daarmee trap je vanzelf in alle valkuilen van zelfoverschatting en is de kans op iets wat kwalitatief nog ergens op een of andere schaal scoort behoorlijk minimaal. Al is het alleen maar doordat niemand met kennis van zaken je algoritme heeft beoordeeld. Weer een aanname die ik doe, maar eentje waarvan ik zeker weet dat die waar is. Dit zal ik kracht bijzetten door te vertellen dat ik vroeger ook ooit voor de lol mijn eigen encryptie gemaakt had, waarvan ook het algoritme geheim moest blijven, en waarvan ik dacht dat het vrijwel onkraakbaar was. Het voldeed verder aan alle criteria die jij genoemd hebt. Ik heb daarover een presentatie gehouden binnen het kader van een crypto-college en de professor had zelfs zonder toegang tot de software tijdens de presentatie nog een aantal pijnpunten gegokt(!) waar ik zelf niet aan gedacht had, en hij had gelijk. Met die zaken in het achterhoofd heb ik vervolgens met een medestudent een eigen cryptanalyse gedaan, mijn algoritme helemaal afgeschoten, en een goed punt gekregen voor de analyse. Zonder de opmerkingen van de professor had ik op dat moment die analyse niet fatsoenlijk kunnen doen. Je krijgt in de ontwerpfase namelijk al te maken met ontzettende tunnelvisie omdat je alle aanvalsvectoren die je zelf kan bedenken al hebt afgedekt. Daarna heb ik nooit meer aan dat algoritme gewerkt en ben ik gewoon de gangbare algoritmen en implementaties gaan gebruiken.
De aanname dat ik maar één persoon ben die er aan werkt.
Overal in je post staat "ik" en praat je in enkelvoud. Vind ik geen enorm rare aanname trouwens.
De aanname dat één persoon nooit iets zo complex zou kunnen maken als iets wat op github staat.
Ik weet niet waar ik die aanname gedaan heb, de enige aanname die ik gedaan heb is dat één persoon die op jouw manier claims doet over crypto niet genoeg kennis heeft om te kunnen beoordelen dat hij niet genoeg kennis heeft om dit op een correcte manier zelf te kunnen maken zonder hulp van buitenaf. Overigens lijk je met deze aanname de voorgaande aanname te bevestigen, maar soit.
Even voor de duidelijkheid; Ik ben zeer zeker geen cryptograaf en weet vrij weinig over cryptografie. Maar ik weet meer dan genoeg over websecurity dat mijn producten nog nooit met hacks te maken hebben gehad.
Aanname van mij: jouw producten zijn niet interessant genoeg om naar te kijken.
Ik weet ook dat ik niet alles weet en daarom huur ik white-hats in om lekken in mijn producten te vinden i.p.v. dit zelf te doen.
Als je hiervoor openstaat, zou ik deze white-hats of zeker een cryptograaf dan onder geheimhouding laten kijken naar jouw code zodat ze een oordeel kunnen vellen over de kwaliteit van je algoritme, de toegevoegde waarde ervan en alle voor- en nadelen aan het gebruik. Zeker vanwege de volgende quote van je:
Ik kan niet ontkennen dat ik wel eens custom measures heb gezien die inderdaad zo lek zijn als een mandje en juist gaten creëeren.
Doe ermee wat je wilt.
Nou ik zal je een leuke quote vertellen die ik bij een lecture van Phil Zimmermann de bedenker van PGP (die ook niet zijn eigen crypto algoritme heeft bedacht) "You can never crack your own cryptography, since it's either impossible to crack, or you're not smart enough to crack it".

En aangezien je taalgebruik ga ik er niet vanuit dat je een wiskundige met PhD in cryptography bent. Een hash is bovendien niet relevant in deze discussie, quantum supremacy heeft op de gebruikte hashing algoritmes geen invloed. Het draait hier om het feit dat er collisions gevonden moeten worden om deze algoritme onbruikbaar te maken.
Gelukkig heb ik ook geen "echte" eigen encryptie gemaakt. Ik heb basically een dynamische salt gemaakt als EXTRA maatregel welke ik implementeer vóór ik de standaard moderne en goedgekeurde encrypties gebruik, zoals al eerder aangegeven. Dit is zó enorm vermoeiend.
Wat vermoeiend is, is dat je zelf de terminologie blijkbaar niet kent en dan anderen gaat afzeiken als ze niet lijken te snappen wat je bedoelt.
Ikzelf denk dat het antwoord ja erop zal zijn, reden, elk slot/kluis/encryptie wat er komt, zal een keer bij de verkeerde partij in handen komen en die pluizen alles goed uit en voila, slot/kluis gaan al open, encryptie zal dus ook op een gegeven moment gekraakt worden. Maar dit is een gedachte O-)
Om te beginnen alles achter de compiler en assembler. Tenminste, ligt er aan wie je allemaal met 'ons' bedoeld maar zoveel Assembly programmeurs of reverse engineers zijn er niet.

Maar de historie van encryptie is een wetenschap op zich, die van de mathematica. En tegenwoordig zit er overal hardwarematige encryptie in. Voordat de data in userspace is, zitten er verschillende manipulaties tussen. Laat staan voordat het OS opstart. Dan kom je idd bij bcrypt en blake3 uit.

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 06:33]

Ah, we zijn NOG STEEDS 10-20 jaar verwijderd van kwantumcomputers. Volgens de experts.
Nee, we zijn 10 tot 20 jaar weg van quantumcomputers die asymmetrische encryptie kunnen ontcijferen.
IDD, quantum-computers bestaan al, maar momenteel zijn ze nog goed voor het kraken van 4 bit RSA, en dat lukt mij ook met pen-en-papier.
10-20 jaar voor quantum computers op grote schaal lees ik hierin. Als de AIVD het nu al kan gaan ze dat natuurlijk niet roepen. Maar als iedereen het kan dan is het een probleem </aluhoedje>
Misschien draaien ze alleen op kernfusie. :+
Dit is bij mensen die bezig zijn met crypto al decennia bekend.
In iets als StrongSwan kom ik al jaren post-quantum encryptie, signatures, etc. tegen. Gebruiken doe ik het niet, volgens mij is het daar ook nog niet klaar voor, maar er wordt inderdaad al heel lang aan gesleuteld.
Bekend is een ding, er wat mee doen een ander. Als de belangrijke veiligheidsdiensten en ICT dienstverleners er adviezen over uitbrengen dan heeft die arme CIO in de directie-kamer tenminste iets om het onder de aandacht te brengen.
Vraag me vooral af waarom AIVD hier mee komt en niet NCSC. Nog even en ze gaan een alternatief adviseren waar ze toevallig zelf ook de decryptiesleutels van hebben…
Denk je dat er tegenwoordig nog een nieuw encryptie algoritme word geaccepteerd waarvan de algoritmes geheim zijn?
Vraag me vooral af waarom AIVD hier mee komt en niet NCSC. Nog even en ze gaan een alternatief adviseren waar ze toevallig zelf ook de decryptiesleutels van hebben…
Omdat de AIVD en NCSC andere missies hebben. AIVD zit op de kant van geheimhouding en versleuteling (gegeven de achtergrond in spionage), terwijl het NCSC op "gewone" beveiliging zit.
Een instantie zoals AIVD zou volgens mij helemaal niet in publieke discussies moeten stappen. Zij hebben een andere taak. Waarom doen ze dit, het is toch geen James Bond-film |:(

Dit onderwerp is inderdaad voor de NCSC, ik geef RvdMeer groot gelijk.

Maar ja, diverse zaken verschuiven. Het NCTV deed en doet zelfs zaken die helemaal niet mogen. MIVD idem dito. Het lijkt wel of ze met elkaar concurreren. Nogal amateuristisch.

Maar dit wordt off topic, ik zal ermee stoppen.

Op dit item kan niet meer gereageerd worden.