Proton zet postquantumversleuteling tijdelijk stop na synchronisatieproblemen

Proton heeft de release van postquantumversleuteling tijdelijk uitgeschakeld. De functionaliteit leverde problemen op, onder andere met synchronisatie met Windows. Het is nog niet bekend wanneer PQC weer beschikbaar wordt.

Proton meldt dat in een reactie op Reddit. Het bedrijf stopt in ieder geval tijdelijk met postquantumversleuteling. Proton bracht eerder deze maand postquantumversleuteling uit voor zijn e-maildienst, gebaseerd op OpenPGP v6. Het gaat om een optionele functie die gebruikers zelf moeten inschakelen. Proton zegt nu dat die functionaliteit problemen veroorzaakt bij het synchroniseren.

Het bedrijf zegt in een update van de originele blogpost dat het bekend is met 'meldingen dat Proton Drive voor Windows-gebruikers synchronisatieproblemen heeft' nadat de postquantumversleutelingsfunctie is ingeschakeld. "We hebben de opt-in tijdelijk uitgeschakeld en werken aan een oplossing", zegt het bedrijf. Het is niet duidelijk wanneer de functie weer beschikbaar wordt; Proton noemt geen tijdlijn.

Postquantumcryptografie (of PQC) is een vorm van versleuteling die moeilijker te kraken is door quantumcomputers. Dat wordt met name in de toekomst belangrijk als quantumcomputers bruikbaarder worden. Onlangs riep bijvoorbeeld de Nederlandse Algemene Rekenkamer overheden nog op haast te maken met de implementatie van postquantumcryptografie.

Reacties (45)

[musiman]

Dit is een van de lastige dingen bij het migreren naar PQC. Je bent afhankelijk van een enorm aantal zaken.

Ten eerste binnen jouw eigen netwerk. Welke devices zijn wel of niet compatibel? Hoe ga je migreren, alles in één keer of gefaseerd? In het laatste geval, kan de nog niet gemigreerde omgeving wel overweg met de onderdelen die al aangepakt zijn?

Ten tweede ben je afhankelijk van derde partijen waar je mee samenwerkt. In hoeverre zijn die al bezig met hun migratie? Zouden er compatibiliteitsproblemen kunnen ontstaan tijdens jouw migratie?

Ten derde ben je afhankelijk van leveranciers. Maken zij hun huidige of nieuwe versies van de apparatuur c.q. software die jij afneemt, geschikt voor PQC?

Ten vierde ben je afhankelijk van compliance en wetgeving. Stel dat je nu al overgaat naar de op dit moment beschikbare oplossingen, maar komt er daarna wetgeving die niet strookt met hetgeen jij hebt gedaan, dan kun je overnieuw beginnen.

Ten vijfde, wanneer je een pionier bent op het gebied van PQC, dan loop je het risico dat de implementatie fouten bevat. Het betreft nieuwe materie en de kans op foutieve of onveilige implementatie is hierdoor groter dan wanneer het "bewezen en bekende" zaken betreft.

Daarom hebben diverse organisaties een tijdspad gedefinieerd van 10 jaar, waarin je jouw migratie stapsgewijs doorloopt. Ondermeer het Engelse NCSC heeft dit vorig jaar gepubliceerd, maar ook onze eigen AIVD en NCSC hebben dergelijke adviezen die je kunnen helpen om jouw bedrijf "quantumproof" te maken.

Met de huidige ontwikkelingen op het gebied van kwantumcomputers is de verwachting dat over 10 tot 15 jaar de RSA versleuteling gekraakt wordt, steeds realistischer. Vooral omdat Google met hun Google Willow nu heeft bewezen dat bij het opschalen van het aantal qubits, het foutpercentage níét meer oploopt, maar juist daalt!!! Dus opschalen is niet meer een theorie, maar praktisch haalbaar gebleken.

Initiatieven, zoals die van Proton, zijn heel goed om de eventuele problemen bij het implementeren van PQC aan het licht te brengen, zoals deze (voorlopige) incompatibiliteit met Windows.

[Bedge85]

Binnen PGP speelt ook het probleem mee GnuPG, de meest gebruikte OpenPGP tool die naast mailverificatie en versleuteling ook door veel package managers wordt gebruikt om te verifiëren of software juist is ondertekend, is afgesplitst van OpenPGP en is verdergegaan met een eigen fork van de PGP standaard, LibrePGP.

Dit betekent dat OpenPGP en de meest gebruikte PGP‑tool nu niet meer compatibel zijn met elkaar. Dat veroorzaakt problemen, want mails met PGP ondertekenen is al een vrij technisch verhaal. Als je PQC‑PGP‑encryptie wilt gebruiken, moet je bovendien rekening houden of de implementatie de LibrePGP‑ of de OpenPGP‑standaard gebruikt.

Proton heeft gekozen voor de officele OpenPGP v6 standaard. Ik hoop dat er uiteindelijk een goede oplossing komt. Als ik het goed heb gezien, maakt Debian nog gebruik van GnuPG, terwijl Fedora al is overgestapt op Sequoia PGP, dat de nieuwe officiële OpenPGP v6 standaard ondersteunt.

[Reactie gewijzigd door Bedge85 op 24 mei 2026 11:53]

[N8w8]

Debian gebruikt tegenwoordig ook Sequoia (sinds apt 2.9.19 van 1,5 jaar geleden).
Het apt pakket "suggests" wel nog steeds GnuPG, weet niet waarom maar blijkbaar is t nog wel ergens goed voor, iig niet vereist.

[diego_wen]

Hoezo"Postquantumcryptografie (of PQC) is een vorm van versleuteling die moeilijker te kraken is door quantumcomputers."

Idee is juist dat deze vorm juist niet te kraken is door quantum

Volgens o.a. overheidssite: https://www.rijksoverheid.nl/actueel/nieuws/2025/07/10/quantumcomputers-komen-eraan : "Post-Quantum Cryptografie biedt een oplossing. Dit is cryptografie die gebaseerd is op wiskundige problemen waarvan wordt aangenomen dat deze ook met een quantumcomputer niet te kraken zijn"

[DvanRaai89]

Alles is te kraken, mits je voldoende geduld hebt. (Gerekend in x leeftijd universum)
Het gaat hier over encryptiealgoritmen waarbij het algoritme van Shor niet effectief is. (Wat bij niet-PQC assymetrische encryptie zoals RSA wel het geval is)
Al kun je natuurlijk nog wel normaal bruteforcen, daarom moet de sleutel uit voldoende bits/bytes bestaan.
Een 32 bit PQC-gegeneerde sleutel kraken is zo gepiept, ook op een normale computer.

[Reactie gewijzigd door DvanRaai89 op 24 mei 2026 15:04]

[diego_wen]

Alles is te kraken, maar niet per definitie door Quantumcomputers.

Het punt is dat Quantumcomputers heel goed zijn in specifieke zaken te "processen", en andere dingen helemaal niet kunnen. Idee vam de PQC algoritmes is dat dat algoritmes zijn die niet te kraken zijn door Quantumcomputers.

En dat is nu tegenstrijdig in het huidige artikel.

[Reactie gewijzigd door diego_wen op 24 mei 2026 11:05]

[Terracotta]

Het artikel is correct en niet tegenstrijdig, meer nog, de auteur valt niet in de bullshitbingo over PQC waarbij mensen denken: problem solved.

PQC algoritmes met voldoende sterke sleutels zijn en moeilijk te kraken door quantum computers en door normale. De cryptograaf die u zegt dat het niet kraakbaar is kan je naar huis sturen.

[diego_wen]

Ik zeg ook niet dat het niet kraakbaar is, alles is idd uiteindelijk kraakbaar, het gaat over het feit dat het niet kraakbaar is door QC. En dat geeft het artikel verkeerd weer

[keejoz]

Jammer dat de mensen waar je op reageert zelf geen opzoekwerk doen. Je hebt gewoon volledig gelijk.

[musiman]

Alle PQ standaarden zijn gebaseerd op bepaalde technieken, zoals latices, codebased, etc. Op DIT moment lijkt het erop dat kwantumcomputers niet snel in staat zullen zijn om die te kraken, maar dat is allerminst zeker. Niet voor niks zijn er voor encryptie en voor digitale handtekeningen JUIST algoritmes gekozen tot standaard die NIET dezelfde techniek gebruiken. Want, wanneer het gebruik van bijvoorbeeld latices TOCH een kwetsbaarheid lijkt te bevatten of een slimme meid een algoritme bedenkt dat het vinden van de dichtsbijzijnde punt in het multidimensionale doolhof van de latice en alle algoritmen gebruik zouden maken van latices, dan hebben we niks meer achter de hand...

Dus... PQC is NIET ONKRAAKBAAR door QC. Het is echter NIET BEKEND of ze (SNEL) kraakbaar kunnen zijn.

Lees even de informatie die NIST heeft gepubliceerd over de gekozen winnaars, dan zul je precies dat lezen.

[Reactie gewijzigd door musiman op 24 mei 2026 16:35]

[mphilipp]

Dus... PQC is NIET ONKRAAKBAAR door QC. Het is echter NIET BEKEND of ze (SNEL) kraakbaar kunnen zijn.

Precies dat. Voorlopig hebben we nog geen quantumcomputers die op grote schaal ingezet kunnen worden. En ik ben ervan overtuigd dat als ze er zijn (of aankomen) er een manier wordt ontwikkeld om alles wat tot nu toen encrypted is met 'normale' computers open ligt.
Kijk maar eens wat de huidige AI technologie al kan qua lekken zoeken en wiskundige problemen oplossen. Stel dat je a)een paar jaar verder bent en b)die AI modellen op een quantumcomputer draait.
Zijn we dan a)fucked b)screwed c)doomed of d)all of the above?

[StCreed]

Ik verwacht niet dat quantum computers heel snel een standaard computer platform gaan worden. Er zijn nog enorme problemen met de snelheid en stabiliteit waar geen goede oplossingen voor zijn, en voor veel algoritmen is onlangs wiskundig bewezen dat gewone computers even snel kunnen zijn. Bij quantum computers werd namelijk aangenomen dat alle informatie al beschikbaar was in het geheugen. Zodra je dat loslaat, zijn ze opeens helemaal niet zo veel sneller waar het gaat om zaken die veel geheugentoegang vragen. Met name bij AI is dat dus precies het geval.

Voor encryptie is geheugentoegang minder belangrijk: een sleutel heeft een constante omvang.

[mphilipp]

Niets is nog echt zeker op dit moment. Maar uiteindelijk is het misschien maar één doorbraak van ons verwijderd, waarmee ze alle huidige problemen oplossen en hebben we over 5 jaar een quantumchip in onze mainstream telefoon zitten. Zeg nooit nooit wat dat betreft. Misschien komt er straks iemand die de problemen op een andere manier aanpakt oid.

[uiltje]

Nou lijkt het weer alsof de algoritmen niet specifiek zijn gekozen om het quantum computers lastig te maken. Dat is echter wel het geval.

Ook klopt het niet dat de encryptie en handtekeningen per se andere technieken moeten gebruiken. Zowel ML-KEM als ML-DSA zijn immers op lattices gestoeld, en deze zullen ongetwijfeld het meest gebruikt gaan worden, omdat ze tevens redelijk efficiënt zijn. Ik snap dit hele punt ook niet, als bijvoorbeeld ML-KEM gebroken kan worden dan heb je nog steeds niets aan een handtekening die op een ander algoritme is gestoeld, de confidentialiteit is immers nog steeds gecompromitteerd.

Van geen van de cryptografische algoritmen (op one-time-password na) weten we of ze kraakbaar zijn, maar het lijkt uiterst onwaarschijnlijk dat de huidige PQC's gekraakt worden - er is in ieder geval geen enkele indicatie van enorme kwetsbaarheden. Side channel attacks kunnen wel een probleem zijn, het is altijd lastig om algoritmen hiertegen te beschermen, maar PQC algoritmen zijn over het algemeen wat kwetsbaarder dan andere algo's.

[Bedge85]

Hij stelt

Idee is juist dat deze vorm juist niet te kraken is door quantum

Hierbij lijkt het alsof quantum wordt gebruikt als soort magische toverwoord is waardoor kraken niet meer mogelijk is.

Het probleem is, je kunt nooit bewijzen dat iets niet te kraken is. Je kunt enkel bewijzen dat iets wel te kraken is.

[Terracotta]

Dat geeft het artikel niet verkeerd weer. Het is geen feit dat de Post-Quantum Cryptographie (PQC) niet door Quantum Computers kraakbaar is, het is een aanname gebaseerd op de huidige informatie die we er over hebben. Er zijn überhaupt praktisch geen QC's, er zijn relatief weinig specialisten in en het zal nog moeten blijken, éénmaal QC's wijdverspreid zijn en deze protocollen niet overbodig worden door het bestaan van QC's. Het blijft een aanname en is geen feit.

[DvanRaai89]

Het idee van PQC is dat die algoritme NIET vatbaar zijn voor de "versnellingen" die mogelijk worden gemaakt omdat je het algoritme van Shor kunt draaien.

Je blijft aassen op een onbestaande tegenstrijdigheid. Ik raad je aan mijn vorige reactie nog eens goed te lezen.

[diego_wen]

Misschien moet je je wat verdiepen in wat QC kunnen en vooral wat ze niet kunnen, daar zit 'm de crux. Niet voor niks blijven "gewone" computers nodig naast QC. PQC is zo ontworpen dat een QC dat niet kan kraken, een gewonen computer wellicht wel als je een paar eeuwen hebt. Het artikel geeft dit dus verkeerd weer.

[floydr]

Quantum algoritmes zijn een superset van de reguliere algoritmes, zodoende bestaan er geen problemen waarvoor een quantum computer asymptomatisch slechter is dan een normale computer. Die normale computers zijn natuurlijk wel veel langer doorontwikkeld en erg snel inmiddels, maar puur op de relatieve groei van de rekentijd ten opzichte van de grootte van het probleem dat je probeert op te lossen zijn quantum computers nooit slechter dan de normale.

[uiltje]

Je reactie is verre van correct. Het is wel mogelijk om klassieke problemen met QC's op te lossen, maar dit kost heel veel met elkaar verbonden qbits. Het is een van de redenen waarom symmetrische algoritmen zoals AES en SHA-256 niet makkelijk te kraken zijn, want het betekend dat je het algoritme met een QC moet coderen (onderdeel van Grover's algoritme). QC's werken fundamenteel anders dan gewone computers en het is lastig om gewone computers ermee te vervangen.

[Reactie gewijzigd door uiltje op 25 mei 2026 23:52]

[floydr]

De enige beperking die QC's hebben is dat alle gates reversibel moeten zijn. Dat valt op te lossen met wat overhead.

[uiltje]

Vast, maar het punt is dat een quantum gate niet even makkelijk te maken is als een standaard gate, al is het maar vanwege de benodigde entanglement.

[dasiro]

als je encryption-keys of zelfs het volledige algoritme sneller veranderd dan de absolute tijd dat nodig is om te decrypten (dus de verkorte tijd door parallellisering meegerekend), dan heb je een grotere zekerheid, niet door de encryptie op zich, maar door het feit dat er regelmatig op de reset-knop wordt geduwd wat in het decryptieproces waarschijnlijk ook zal zorgen voor invalidatie van voortgang die opnieuw zal moeten worden gevalideerd.

[DvanRaai89]

? Je kunt de gevens toch onderscheppen, opslaan en daarna ontsleutelen?
Wikipedia: Harvest now, decrypt later

[dasiro]

Dat kan uiteraard, maar als je data dan niet meer relevant is, bvb voor (near) realtime-communication of transactions maakt dat minder of zelfs helemaal niet uit. Als je coördinaten voor een bombardement doorstuurt, wil je niet dat die onderschept en gewijzigd kunnen worden voor ze aankomen. Dat je een uur later het resultaat hebt en eventueel een soortgelijk bericht kan decypten maakt dan niet meer uit.

[lenwar]

Dat je een uur later het resultaat hebt en eventueel een soortgelijk bericht kan decypten maakt dan niet meer uit.

Behalve als het bombardement mislukte en dat je eigenlijk niet wil, daar de ontvangende wist dat je het van plan was 🤨.

Maar in de basis heb je gelijk. Iets hoeft ‘slechts’ veilig te zijn, zolang het nodig/relevant is. Het enige probleem is, is dat dat niet altijd duidelijk is hoelang die relevantie er is.

[fastedje]

Er is wel een onkraakbare encryptie: One -Time pad, waarbij de encryption key compleet willekeurig is en even lang is als het versleutelde bericht. In feite is dat hetzelfde als complete ruis proveren te kraken.

[lenwar]

Het is een beetje kort door de bocht hoe je het nu verwoord. Het is ‘cryptografisch onkraakbaar’. Dat is wat anders. Er zal nooit een cryptografische methode komen om de versleuteling te breken, omdat er geen patroon/wiskundige repetitie/formule is. Maar het is wel te ‘brute-forcen’.

Als je die otp overigens altijd even lang als het oorspronkelijke bericht geef je onnodig veel informatie weg. Je kunt hem beter langer maken. Dan weet de malafide kant niet hoe lang het bericht moet worden. 😊

[uiltje]

Een OTP is niet te bruteforcen, dat heb je toch verkeerd begrepen.

[lenwar]

Als je een bestand hebt van 20 bytes en een OTP van bytes, dan kun je toch die 20 bytes proberen na te bouwen.

Je begint met 20 keer 0, daarna 19 keer 0, 1 keer 1, enz

Op een gegeven moment heb je de OTP opnieuw gebouwd. (Je komt hem per ongeluk tegen.)

Dat is te doen. Heb je een bestand van 20MB, dan wordt dat al minder grappig.


Je moet dan uiteraard ook weten waar je naar zoekt. (Een binary blob herkennen is lastiger dan een BSN of bankrekeningnummer, waar een ‘normering’ aan vast zit)

[Reactie gewijzigd door lenwar op 26 mei 2026 06:32]

[MacGyverNL]

Het hele punt van one-time pad is dat je dat níet kunt. Het is juist niet "cryptografisch onkraakbaar", dat is wat AES-128 en kornuiten zijn. OTP is "informatie-theoretisch onkraakbaar". Dat is een strikt sterkere garantie, een wiskundig te bewijzen eigenschap die stelt dat een aanvaller, zelfs met ongelimiteerde rekenkracht en ongelimiteerde tijd, nooit zal kunnen achterhalen wat de plaintext nou echt was.

Zie het zo: jouw voorgestelde "brute force" zal uiteindelijk elke mogelijke valide plaintext opleveren, en je hebt géén informatie over welke correct is. Dus bijvoorbeeld bij BSNs: tuurlijk, als je op AAAAAAAAA uitkomt weet je dat dat niet klopte, dat is immers geen BSN. Maar je zult ook 000000000 en 000000001 en 000000002 etc. krijgen, en je weet niet welke daarvan nou bedoeld was. Ook als er check-getallen in zitten, zoals bij bankrekeningnummers, zul je nog steeds altijd alle mogelijke valide bankrekeningnummers enumereren, zonder te weten welke nou correct was.

Dat gezegd hebbend is OTP wel nutteloos in de praktijk, maar om compleet ándere redenen, zoals gebrek aan authenticatie van de ciphertext, of de onwerkbaarheid van die hoeveelheid daadwerkelijk willekeurig sleutelmateriaal dat overgeheveld moet worden naar de andere kant.

edit:
Oh, en wat betreft je "dat is te doen": daar verkijk je je toch behoorlijk op. 20 bytes op die manier proberen te ontsleutelen is 20*8 = 160 bits. Alle combinaties van 160 bits alleen maar enumereren duurt al langer dan de verwachte hittedood van 't universum. Het is minder werk om gewoon alle mogelijke plaintexts te enumereren, en daar zit dan toevallig de juiste tussen, maar je gaat dus nooit weten welke de juiste is.

[Reactie gewijzigd door MacGyverNL op 27 mei 2026 02:58]

[uiltje]

--- al genoemt

[Reactie gewijzigd door uiltje op 26 mei 2026 00:05]

[ccnl]

In jouw tekst staat het woord 'aangenomen', niemand weet het of het moeilijker of niet te kraken is.

[Terracotta]

Een negatief bewijzen is moeilijk. Met de huidige kennis kan men concluderen dat het moeilijker te kraken is dan rsa, maar die kennis kan groeien.

[TTMJ!]

Mijn hersenen kraken. Hoe werkt deze versleuteling dan wanneer het zelfs door een quantum computer niet kan worden gekraakt?

[chrome moral]

“Postquantumcryptografie (of PQC) is een vorm van versleuteling die moeilijker te kraken is door quantumcomputers.”

Dat gebruik ik zelf al; AES256 is ook moeilijk te kraken door quantumcomputers. Ik gebruik dat al meer dan 10 jaar overigens

[musiman]

Uhm... AES-256 zal op den duur OOK kraakbaar zijn door kwantumcomputers, het duurt echter wat langer dan bij asymmetrische encryptie.

Dus wat je zegt is kolder. Niet voor niks is er de ML-KEM standaard gekomen ter VERVANGING van AES...

[Reactie gewijzigd door musiman op 24 mei 2026 15:56]

[MacGyverNL]

Sorry, maar wat jij zegt is óók kolder: ofwel weet je ook niet waar je 't over hebt, ofwel haal je onbewust wat standaarden door elkaar.

AES is een symmetrisch algoritme. chrome moral maakt een loze doch correcte opmerking over dat symmetrische cryptografie met dubbele sleutellengte moeilijk genoeg te kraken is voor een quantum computer -- op z'n slechtst is het "even slecht" als AES-128 in de pre-quantum setting en die vinden we ook goed genoeg. Overigens is er wat discussie binnen de wetenschap over de toepasbaarheid van Grover's algoritme, en of we wel écht de sleutellengte moeten verdubbelen voor symmetrische cryptografie, dus of AES-128 niet tóch eigenlijk genoeg is. Maar of we nu sleutellengtes verdubbelen of niet: we zijn niet bezig met het vervangen van de symmetrische cryptografie, omdat symmetrische cryptografie niet gebaseerd is op een wiskundig probleem dat makkelijk aan te vallen is met Shor's algoritme; het is simpelweg dat Grover's algoritme "beter is" in bruteforcen van een zoekprobleem en daarmee, als het algoritme uberhaupt inderdaad op die manier uit te voeren is, de effectieve sleutellengte halveert.

De situatie is behoorlijk anders voor asymmetrische cryptografie: de gangbare methodes daar zijn gebaseerd op twee wiskundige concepten: hoe moeilijk het is om een getal te factoriseren in priemgetallen of het discreet logaritme uit te voeren. Deze zijn wél makkelijk aan te vallen met Shor's algoritme (zogauw het lukt quantum computers te bouwen die dat kunnen uitvoeren voor de relevante sleutellengtes), in de zin dat die problemen van "duurt bij deze sleutellengte langer dan de hittedood van het universum" naar "over een minuut of tien heb je het antwoord, ongeacht sleutellengte" gaan, dus dáár zoeken we vervanging voor.

Nu de crux: vrijwel alle daadwerkelijke versleuteling, inclusief de versleuteling in PGP, is uiteindelijk versleuteling met een symmetrisch algoritme. Maar wat chrome moral ofwel voor de grap niet opmerkt, ofwel ook niet weet dat relevant is in deze setting, en wat de opmerking loos maakt, is dat je voor een symmetrisch algoritme dezelfde sleutel met je communicatiepartner moet overeenkomen. En daar gebruiken we in de praktijk alleen maar asymmetrische methodes voor. Als je een symmetrische sleutel overeenkomt via een voor een quantum computer makkelijk te kraken asymmetrisch algoritme, dan heb je nog steeds niks aan de "moeilijk te kraken" symmetrische encryptie want je aanvaller hóeft die niet te kraken, die weet gewoon wat de sleutel is. ML-KEM is een post-quantum-bestendige asymmetrische manier om sleutelmateriaal voor het symmetrische algoritme over te hevelen, het is niet de vervanging voor het symmetrische algoritme.

[Reactie gewijzigd door MacGyverNL op 24 mei 2026 16:38]

[Bedge85]

Voor mij als leek.

1. Betekent dit in de regel dat symmetrisch versleuteling in de regel als post quantum bestendig wordt gezien.
2. Als we het over post quantum hebben het altijd over het asymetrische versleuteling gaat.
3. Als ik je jouw verhaal goed begrijp wordt bij SSL eerst via asymmetrische methode een sleutel uitgewisseld waarna de verbinding overgaat op symmetrische versleuteling?

[MacGyverNL]

Voor mij als leek.

1. Betekent dit in de regel dat symmetrisch versleuteling in de regel als post quantum bestendig wordt gezien.

Ja, met als kanttekening dat als je nu sleutellengtes van 128 bits gebruikt, dat je mógelijk wil overstappen op sleutellengtes van 256 bits (dus bijvoorbeeld van AES-128 naar AES-256) om dezelfde mate van veiligheid te behouden. Maar of dat "te voorzichtig" is, en eigenlijk helemaal niet nodig, daar is nog discussie over. Maar je hoeft níet van algoritme te wisselen.

2. Als we het over post quantum hebben het altijd over het asymetrische versleuteling gaat.

Als je het als leek ergens tegenkomt in de zin van "post-quantum-cryptografie wordt uitgerold in systeem X" vrijwel altijd wel, ja -- behalve dat het niet alleen over versleuteling gaat; ook asymmetrische authenticatie moet post-quantum gemaakt worden. Daar wordt momenteel heel veel moeite in gestoken want daar zijn we nog niet zo ver mee als bij versleuteling. Maar binnen het vakgebied kan het natuurlijk óók gaan over vraagstukken zoals de kanttekening bij 1.

3. Als ik je jouw verhaal goed begrijp wordt bij SSL eerst via asymmetrische methode een sleutel uitgewisseld waarna de verbinding overgaat op symmetrische versleuteling?

Ja. En datzelfde patroon zie je vrijwel overal waar "asymmetrische versleuteling" plaatsvindt, bijvoorbeeld bij PGP: de hele e-mail wordt symmetrisch versleuteld met een willekeurig gegenereerde sleutel, en díe symmetrische sleutel wordt dan asymmetrisch versleuteld aan de e-mail toegevoegd. Bij ontvangst gebruikt de ontvanger de asymmetrische methode om de symmetrische sleutel te verkrijgen, en gebruikt dan die sleutel om de e-mail zelf te ontsleutelen. De reden hiervoor is dat asymmetrische versleuteling bepaalde beperkingen heeft (qua berichtlengte, maar ook qua snelheid van uitvoeren) die makkelijker op te lossen zijn door deze combinatie van asymmetrisch + symmetrisch toe te passen, dan compleet asymmetrisch te proberen. De vakterm voor dat asymmetrische deel is overigens "Key Exchange / Encapsulation Mechanism", vandaar de "KEM" in "ML-KEM".

[uiltje]

We hoeven voor authenticatie ook minder op te schieten dan voor versleuteling omdat het scenario store-and-decrypt-later er niet is. Op het moment dat een QC computer dichterbij komt moeten we het natuurlijk wel hebben opgelost, maar voor nu: als je je authentiseert met RSA of ECC dan is die authenticatie over 10 jaar vast niet meer geldig. Maar een bericht kan wel info bevatten die nog steeds interessant is. Vandaar dat ML-KEM ook al in browsers zit en door oa Google al wordt gebruikt.

Grootste probleem zijn embedded devices en smart cards die niet even snel geupdate kunnen worden naar ML-KEM...

[Reactie gewijzigd door uiltje op 26 mei 2026 00:11]

[Commendatore]

Ik neem aan dat dit vooral betekent dat nieuwe gebruikers het niet meer aan kunnen zetten? Het lijkt me namelijk niet dat ze al op deze manier versleutelde data van gebruikers zelf weer om kunnen zetten naar reguliere encryptie.

[Bedge85]

Ik neem aan dat dit vooral betekent dat nieuwe gebruikers het niet meer aan kunnen zetten?

Ja klopt, dit is ook hoe ik het heb begrepen.

Nou was het zo dat als je deze functionaliteit inschakelde al zo dat het enkel werd toegepast op mail en dan enkel op nieuwe mail berichten. Dus oude mail maar ook bestanden in drive en de kalender gebruikten nog gewoon de oude versleutel methode. Er is vanuit de community wel vraag om ook mails die op oude manier zijn versleuteld opnieuw te kunnen versleutelen met de PQC technologie. En Proton heeft aangegeven deze functionaliteit toe te gaan voegen.

[Yongshi]

Beetje ambigu, in het begin zeggen ze dat de hele functie is uitgeschakeld en later enkel de opt-in...

[Cambionn]

Helaas was deze update vanuit Proton al binnen max een paar dagen na release, als het niet dezelfde dag al was. Helaas omdat ik geen tijd had het aan te zetten voor het weer offline ging, en daar ik geen Windows gebruik dus (en überhaupt geen desktop client voor de drive) ook geen issues zou hebben.

Ik kreeg juist ergens mee dat het inmiddels langzaam weer werd uitgerolt, maar dat de uitrol nu voor een kleine groep was en daar steeds meer mensen aan toegevoegd werden. Zit nu elke paar dagen ff te kijken of de optie inmiddels beschikbaar is voor mijn account om er eens mee te spelen. Hopelijk binnenkort.