Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
Huidige encryptie-standaard: minder dan 30 jaar te gaan
14-05-2021, 16:50 door Anoniem, 30 reacties
Kwantumcomputers en cybersecurity: “Ga aan de slag!”!
Zo luidde de voornaamste conclusie van het online symposium dat in maart van dit jaar werd gehouden waarbij 10 experts waren betrokken op het gebied van kwantumcomputers, en ook ca. 200 deelnemers beroepsmatig bij betrokken waren.
De huidige gangbare standaarden voor cryptografische beveiliging zijn naar verwachting al vóór 2050 niet meer veilig voor kwantumcomputers. Veilige en betrouwbare elektronische betalingen zijn sterk afhankelijk van zulke standaarden.
https://www.betaalvereniging.nl/actueel/nieuws/quantum-ga-aan-de-slag/
Dit zou ook betekenen dat dus kan worden verwacht dat informatie die we met de huidige encryptiestandaarden verzenden
al binnen 30 jaar "gekraakt" kan worden als deze encrypted informatie werd afgetapt en opgeslagen,
totdat kwantumcomputers er klaar voor zijn om het allemaal alsnog te kraken.
Dus bijv. als je nu een puber bent, zou het best eens kunnen dat al je geheime internetgebraak uit de puberjaren op straat ligt voordat je 40 jaar oud bent...
Namelijk als deze encrypted informatie nu wordt opgeslagen, en binnen 30 jaar (als de kwantumechniek er klaar voor is)
alsnog allemaal ontsleuteld kan worden.
Dat ziet er vrees ik niet best uit voor sommigen...
Zo luidde de voornaamste conclusie van het online symposium dat in maart van dit jaar werd gehouden waarbij 10 experts waren betrokken op het gebied van kwantumcomputers, en ook ca. 200 deelnemers beroepsmatig bij betrokken waren.
De huidige gangbare standaarden voor cryptografische beveiliging zijn naar verwachting al vóór 2050 niet meer veilig voor kwantumcomputers. Veilige en betrouwbare elektronische betalingen zijn sterk afhankelijk van zulke standaarden.
https://www.betaalvereniging.nl/actueel/nieuws/quantum-ga-aan-de-slag/
Dit zou ook betekenen dat dus kan worden verwacht dat informatie die we met de huidige encryptiestandaarden verzenden
al binnen 30 jaar "gekraakt" kan worden als deze encrypted informatie werd afgetapt en opgeslagen,
totdat kwantumcomputers er klaar voor zijn om het allemaal alsnog te kraken.
Dus bijv. als je nu een puber bent, zou het best eens kunnen dat al je geheime internetgebraak uit de puberjaren op straat ligt voordat je 40 jaar oud bent...
Namelijk als deze encrypted informatie nu wordt opgeslagen, en binnen 30 jaar (als de kwantumechniek er klaar voor is)
alsnog allemaal ontsleuteld kan worden.
Dat ziet er vrees ik niet best uit voor sommigen...
Reacties (30)
Het blijft mensenwerk. Wat 'problematisch' is voor het huidige regime, kan over 30 jaar volledig achterhaald zijn. Terugkijkend op bijvoorbeeld zwarte bladzijden zoals 2020/2021.
Maar reken er maar op dat de ontsleuteling over max.10 jaar al plaatsvindt.
Maar reken er maar op dat de ontsleuteling over max.10 jaar al plaatsvindt.
Door Anoniem: Maar reken er maar op dat de ontsleuteling over max.10 jaar al plaatsvindt.
Welke onderbouwing heb je hier voor?
Door Anoniem:
Maar reken er maar op dat de ontsleuteling over max.10 jaar al plaatsvindt.
Daar is geen enkel zicht op. Quantumcomputing is nu vooral nog een research projectje waar men natuurlijk geldMaar reken er maar op dat de ontsleuteling over max.10 jaar al plaatsvindt.
moet aantrekken en dus met wilde claims komt.
Er is nog geen ENKEL zicht op een "stored program quantum computer".
Men kan alleen hardwired constructies maken voor 1 specifiek probleem, en dan moet dat probleem vrij gekozen kunnen
worden. Er is GEEN ENKEL zicht op het maken van een quantum computer om AES te kraken, dat is alleen maar iets
wat in theorie zou moeten kunnen en waar je als wetenschapper dan naar extrapoleert.
Het is net zo iets als energievoorziening met kernfusie: het is al tientallen jaren "over 40 jaar gaat het lukken".
Factsheet Postkwantumcryptografie
PDF document, 6 pagina's, versie 1.1
https://www.ncsc.nl/documenten/factsheets/2019/juni/01/factsheet-postkwantumcryptografie
Het NCSC adviseert organisaties een actieplan op te stellen. Duidelijk moet zijn binnen welke tijdlijn er maatregelen genomen moeten worden om gegevens tegen kwantumcomputers te beschermen. Aan deze factsheet hebben bijgedragen: Betaalvereniging Nederland, KPN CISO, Ministerie van Veiligheid & Justitie en de NBV.
De komst van de quantumcomputer is dichterbij dan u denkt. Experts voorspellen dat rond 2030-2035 voldoende ontwikkelde quantumcomputers van praktisch nut beschikbaar zijn. Het is mogelijk om de sleuteluitwisseling en de vercijferde data op te slaan en deze later te ontcijferen: "Intercept now, decrypt later".
Experts verwachten dat iedereen rond het jaar 2045 via de cloud capaciteit kan inhuren van een quantumcomputer. Er zijn een aantal oplossingen in ontwikkeling die krachtig genoeg zijn om opgewassen te zijn tegen quantumcomputers. Er wordt gewerkt aan standaardisatie hiervan.
https://www.aivd.nl/documenten/publicaties/2015/04/15/bereid-u-voor-op-de-komst-van-de-quantum-computer
PDF document, 6 pagina's, versie 1.1
https://www.ncsc.nl/documenten/factsheets/2019/juni/01/factsheet-postkwantumcryptografie
Het NCSC adviseert organisaties een actieplan op te stellen. Duidelijk moet zijn binnen welke tijdlijn er maatregelen genomen moeten worden om gegevens tegen kwantumcomputers te beschermen. Aan deze factsheet hebben bijgedragen: Betaalvereniging Nederland, KPN CISO, Ministerie van Veiligheid & Justitie en de NBV.
De komst van de quantumcomputer is dichterbij dan u denkt. Experts voorspellen dat rond 2030-2035 voldoende ontwikkelde quantumcomputers van praktisch nut beschikbaar zijn. Het is mogelijk om de sleuteluitwisseling en de vercijferde data op te slaan en deze later te ontcijferen: "Intercept now, decrypt later".
Experts verwachten dat iedereen rond het jaar 2045 via de cloud capaciteit kan inhuren van een quantumcomputer. Er zijn een aantal oplossingen in ontwikkeling die krachtig genoeg zijn om opgewassen te zijn tegen quantumcomputers. Er wordt gewerkt aan standaardisatie hiervan.
https://www.aivd.nl/documenten/publicaties/2015/04/15/bereid-u-voor-op-de-komst-van-de-quantum-computer
Er is GEEN ENKEL zicht op het maken van een quantum computer om AES te kraken, dat is alleen maar iets
wat in theorie zou moeten kunnen en waar je als wetenschapper dan naar extrapoleert.
Dat is het punt niet. Om met AES versleutelde informatie te kraken hoef je meestal AES niet te kunnen kraken.wat in theorie zou moeten kunnen en waar je als wetenschapper dan naar extrapoleert.
Het zwakke punt in het huidige versleutelingsmechanisme is vooral het "gedeelde geheim" dat wordt uitgewisseld
en dat vervolgens bij de initialistaie van de versleuteling wordt gebruikt.
Wanneer dit gedeelde geheim kan worden blootgelegd, komt de data ook bloot te liggen.
AES is hierbij slechts een algoritme, dat kan iedereen nabootsen,
en daarom dus ook de onderliggende plain data als men eenmaal de uitgewisselde sleutels heeft blootgelegd.
China heeft het door: zij zijn al bezig om te leren "vuur met vuur" te bestrijden.
Ik bedoel dit: kwantumtechniek kan je alleen effectief te lijf gaan met.... kwantumtechniek!
Bijvoorbeeld kwantumnetwerken.
Zie https://www.security.nl/posting/698104
Maar in het westen zijn we teveel verdeeld.
We denken hier te vaak dat persoonlijke vrijheid (doen waar je op dat moment zelf het meeste zin in hebt) het ultieme streven is. Of anders boksen we juist tegen elkaar op, of we letten teveel op het geld.
Maar dat alles is een grote vergissing.
Een houding van "laat een ieder lekker doen wat goed is in eigen ogen" leidt naar de afgrond.
Zonder gezamenlijkheid, het samen "de strijd aangaan" om samen te bereiken wat we zouden willen bereiken
en bereid zijn om daarvoor ook de nodige offers te brengen, schoppen we het niet ver, en wordt China de baas in de wereld.
Het is misschien leuk om "halleluja" te roepen voor elke pietluttigheid en er samen nog een keer één op te drinken,
maar met die mentaliteit schiet het voor geen meter op. En we hebben nogal wat te doen en het moet snel.
Bijv. ook ten aanzien van de klimaatverandering.
Ik denk dan: alleen met alle hens aan dek waarbij een ieder zonder klagen zichzelf nuttig maakt,
zullen we met zijn allen een kans maken. Anders niet.
De meeste geslaagde grote projecten op de wereld konden tot stand komen vanwege grootschalige samenwerking
die noeste arbeid leverden, opererend onder solide en betrouwbare leider(s) met voldoende kennis en wijsheid aan boord.
Door Anoniem:
Het zwakke punt in het huidige versleutelingsmechanisme is vooral het "gedeelde geheim" dat wordt uitgewisseld
en dat vervolgens bij de initialistaie van de versleuteling wordt gebruikt.
Wanneer dit gedeelde geheim kan worden blootgelegd, komt de data ook bloot te liggen.
AES is hierbij slechts een algoritme, dat kan iedereen nabootsen,
en daarom dus ook de onderliggende plain data als men eenmaal de uitgewisselde sleutels heeft blootgelegd.
Nouja misschien had ik beter TLS kunnen schrijven. Maar daar is ook geen zicht op. Voorspellingen over wanneer Er is GEEN ENKEL zicht op het maken van een quantum computer om AES te kraken, dat is alleen maar iets
wat in theorie zou moeten kunnen en waar je als wetenschapper dan naar extrapoleert.
Dat is het punt niet. Om met AES versleutelde informatie te kraken hoef je meestal AES niet te kunnen kraken.wat in theorie zou moeten kunnen en waar je als wetenschapper dan naar extrapoleert.
Het zwakke punt in het huidige versleutelingsmechanisme is vooral het "gedeelde geheim" dat wordt uitgewisseld
en dat vervolgens bij de initialistaie van de versleuteling wordt gebruikt.
Wanneer dit gedeelde geheim kan worden blootgelegd, komt de data ook bloot te liggen.
AES is hierbij slechts een algoritme, dat kan iedereen nabootsen,
en daarom dus ook de onderliggende plain data als men eenmaal de uitgewisselde sleutels heeft blootgelegd.
het wel lukt hebben dezelfde waarde als de genoemde voorspellingen wanneer kernfusie lukt (voor energievoorziening).
Het zijn uitspraken die als doel hebben om geld en medewerkers aan te trekken.
De meeste ontwikkelingen van "quantumcomputers" gaan helemaal niet in de richting van een inzetbare computer,
ze lijken veel meer op de "analoge computer" (zoek maar eens op wat dat is). Een apparaat wat je moet verbouwen
als er er iets anders mee wilt gaan doen. Je kunt er hardstikke mooie regelsystemen mee bouwen maar als je
wat anders wilt regelen moet je alle stekertjes eruit trekken en opnieuw beginnen. En zoals het nu gaat kun je niet
een willekeurig probleem definieren en een bijbehorende quantumcomputer bouwen, nee, je moet je probleem laten
bepalen door wat er met je quantumcomputer kan.
"stored program" computers zijn nog een orde van grootte moeilijker en verder weg. Daar is vaak verwarring over, ja.
De meeste geslaagde grote projecten op de wereld konden tot stand komen vanwege grootschalige samenwerking
die noeste arbeid leverden, opererend onder solide en betrouwbare leider(s) met voldoende kennis en wijsheid aan boord.
die noeste arbeid leverden, opererend onder solide en betrouwbare leider(s) met voldoende kennis en wijsheid aan boord.
Kop, spijker, raak!
Nouja misschien had ik beter TLS kunnen schrijven. Maar daar is ook geen zicht op. Voorspellingen over wanneer
het wel lukt hebben dezelfde waarde als de genoemde voorspellingen wanneer kernfusie lukt (voor energievoorziening).
Het zijn uitspraken die als doel hebben om geld en medewerkers aan te trekken.
TLS is een protocol voor datatransport en omvat zowel asymmetrische encryptie (geheime sleuteluitwisseling) als de symmetrische encryptie. (bijv. d.m.v. AES) het wel lukt hebben dezelfde waarde als de genoemde voorspellingen wanneer kernfusie lukt (voor energievoorziening).
Het zijn uitspraken die als doel hebben om geld en medewerkers aan te trekken.
TLS zal kwetsbaar zijn vanwege het stuk asymmetriche encryptie dat in de huidige TLS protocollen zit:
Fabel & fictie: Symmetrische encryptie is veilig
... AES bijvoorbeeld kun je blijven gebruiken. Maar, bedenk dat deze vaak een sleutel gebruiken die met asymmetrische encryptie is gegenereerd. Deze sleutel is kwetsbaar voor de quantumcomputer. Hierbij geldt, de zwakste schakel breekt de keten.
... AES bijvoorbeeld kun je blijven gebruiken. Maar, bedenk dat deze vaak een sleutel gebruiken die met asymmetrische encryptie is gegenereerd. Deze sleutel is kwetsbaar voor de quantumcomputer. Hierbij geldt, de zwakste schakel breekt de keten.
(dit en meer weetjes op https://www.ilionx.com/blog/securitydreigingen-door-quantum-computing-voor-ieder-bedrijf-met-ip-of-privacygevoelige-data-relevant/)
16-05-2021, 00:47 door
Erik van Straten
Door Anoniem: TLS zal kwetsbaar zijn vanwege het stuk asymmetriche encryptie dat in de huidige TLS protocollen zit:
Waarschijnlijk niet als je TLS zonder asymmetrische cryptografie gebruikt, en dat kan in een deel van de gevallen. Ik probeer dit toe te lichten.Versleutelen is zinloos als je niet weet met wie je communiceert; in elk geval de server zal zich moeten authenticeren (bewijzen dat hij is wie hij zegt dat hij is). Dat kan op twee manieren:
A) M.b.v. asymmetrische encryptie: de client krijgt de public key van de server (meestal in een digitaal certificaat dat meestal is ondertekend door een trusted third party) waarbij de server bewijst over de bijbehorende private key te beschikken (zonder die private key prijs te geven);
B) Middels een shared secret, ook bekend als PSK (Pre-Shared Key). In dit geval moet die PSK natuurlijk vooraf, via een ander kanaal, veilig zijn uitgewisseld. Als zowel client als server die PSK als sessiesleutel gebruiken (en die PSK niet gelekt is) weten beide partijen van elkaar wie zij zijn, nl. als ontvangen versleutelde data geen semi-random meuk bevat na ontsleutelen. Nb. PSK kost minder rekenkracht en is daarmee ook geschikt voor kleinere IoT devices.
M.b.t. methode A: aanvankelijk (vele jaren geleden gebruikelijk) genereerde de client een random sessie-sleutel, versleutelde deze met de public key van de server en stuurde het resultaat naar de server. Omdat (als het goed is) alleen de server over de bijpassende private key beschikt, kan alleen de server dat resultaat ontsleutelen, waarna beide partijen over de (symmetrische) sessiesleutel beschikken waar de verbinding vervolgens mee wordt versleuteld. Het is al vele jaren gebruikelijk om dit anders te doen: middels een Diffie-Hellman key agreement (dit wordt meestal een "exchange", DHE, genoemd - maar dat is het niet echt) wordt een sessiesleutel via een soort asymmetrische encryptie overeengekomen. Ter authenticatie ondertekent de server bepaalde parameters met diens private key; doordat de client die signature checkt a.d.h.v. de public key (meestal in een certificaat) authenticeert de server zich. Zowel DHE als het sleutelpaar dat gebruikt wordt voor authenticatie zijn naar verwachting kraakbaar door quantum computers.
Uit https://datatracker.ietf.org/doc/html/rfc8446 (de cijfers heb ik ervoor gezet):
The Transport Layer Security (TLS) Protocol Version 1.3
[...]
TLS supports three basic key exchange modes:
1) (EC)DHE (Diffie-Hellman over either finite fields or elliptic curves)
2) PSK-only
3) PSK with (EC)DHE
[...]
[...]
TLS supports three basic key exchange modes:
1) (EC)DHE (Diffie-Hellman over either finite fields or elliptic curves)
2) PSK-only
3) PSK with (EC)DHE
[...]
Als de PSK in mode 2 "out of band" (via een separaat veilig kanaal) wordt uitgewisseld, is er geen sprake meer van asymmetrische encryptie. In mode 3 (PSK with (EC)DHE) heb je het beste van beide werelden: de sessiesleutel ontstaat dan uit een HMAC (vereenvoudigd een hash van twee achter elkaar geplakte getallen) van de PSK en een via Diffie-Hellman overeengekomen secret. Daarmee heb je in elk geval forward secrecy tot een quantum-computer DH kraakt (dat moet dan wel per sessie). Maar zelfs dan valt de schade mee, de aanvaller kent dan het voor die sessie overeengekomen DH-secret (wat dan niet secret meer is); effectief is dit mechanisme dan gedegradeerd tot een random getal dat plain text naar de andere partij wordt gestuurd. Bij een voldoende sterke HMAC is de sessie-sleutel toch elke sessie anders (forward secrecy) en is het voor een MitM (Man in the Middle) nagenoeg onmogelijk om de PSK te achterhalen.
Voordat iemand op een "slim" idee komt: genoemde RFC waarschuwt er (bovenaan pagina 17) voor dat wachtwoorden over het algemeen te weinig entropie bevatten om veilig als PSK te kunnen worden gebruikt.
Voor het bezoeken van wilkekeurige websites is zo'n PSK natuurlijk niet praktisch, maar wel voor point-to-point verbindingen. Bijv. stunnel ondersteunt PSK (zie https://www.stunnel.org/auth.html).
Kortom, TLS is niet in alle scenario's kwetsbaar voor quantum computers; als je PSK's gebruikt en sterkere hashes + sterkere symmetrische ciphers inzet is TLS waarschijnlijk quantum-proof. DHE en digitale certificaten zoals wij ze nu kennen worden waarschijnlijk wel onbruikbaar door quantum computers, dus daar zullen we wel wat anders voor moeten verzinnen.
Door Erik van Straten:
Versleutelen is zinloos als je niet weet met wie je communiceert; in elk geval de server zal zich moeten authenticeren (bewijzen dat hij is wie hij zegt dat hij is). Dat kan op twee manieren:
A) M.b.v. asymmetrische encryptie: de client krijgt de public key van de server (meestal in een digitaal certificaat dat meestal is ondertekend door een trusted third party) waarbij de server bewijst over de bijbehorende private key te beschikken (zonder die private key prijs te geven);
B) Middels een shared secret, ook bekend als PSK (Pre-Shared Key). In dit geval moet die PSK natuurlijk vooraf, via een ander kanaal, veilig zijn uitgewisseld. Als zowel client als server die PSK als sessiesleutel gebruiken (en die PSK niet gelekt is) weten beide partijen van elkaar wie zij zijn, nl. als ontvangen versleutelde data geen semi-random meuk bevat na ontsleutelen. Nb. PSK kost minder rekenkracht en is daarmee ook geschikt voor kleinere IoT devices.
M.b.t. methode A: aanvankelijk (vele jaren geleden gebruikelijk) genereerde de client een random sessie-sleutel, versleutelde deze met de public key van de server en stuurde het resultaat naar de server. Omdat (als het goed is) alleen de server over de bijpassende private key beschikt, kan alleen de server dat resultaat ontsleutelen, waarna beide partijen over de (symmetrische) sessiesleutel beschikken waar de verbinding vervolgens mee wordt versleuteld. Het is al vele jaren gebruikelijk om dit anders te doen: middels een Diffie-Hellman key agreement (dit wordt meestal een "exchange", DHE, genoemd - maar dat is het niet echt) wordt een sessiesleutel via een soort asymmetrische encryptie overeengekomen. Ter authenticatie ondertekent de server bepaalde parameters met diens private key; doordat de client die signature checkt a.d.h.v. de public key (meestal in een certificaat) authenticeert de server zich. Zowel DHE als het sleutelpaar dat gebruikt wordt voor authenticatie zijn naar verwachting kraakbaar door quantum computers.
Uit https://datatracker.ietf.org/doc/html/rfc8446 (de cijfers heb ik ervoor gezet):
Als de PSK in mode 2 "out of band" (via een separaat veilig kanaal) wordt uitgewisseld, is er geen sprake meer van asymmetrische encryptie. In mode 3 (PSK with (EC)DHE) heb je het beste van beide werelden: de sessiesleutel ontstaat dan uit een HMAC (vereenvoudigd een hash van twee achter elkaar geplakte getallen) van de PSK en een via Diffie-Hellman overeengekomen secret. Daarmee heb je in elk geval forward secrecy tot een quantum-computer DH kraakt (dat moet dan wel per sessie). Maar zelfs dan valt de schade mee, de aanvaller kent dan het voor die sessie overeengekomen DH-secret (wat dan niet secret meer is); effectief is dit mechanisme dan gedegradeerd tot een random getal dat plain text naar de andere partij wordt gestuurd. Bij een voldoende sterke HMAC is de sessie-sleutel toch elke sessie anders (forward secrecy) en is het voor een MitM (Man in the Middle) nagenoeg onmogelijk om de PSK te achterhalen.
Voordat iemand op een "slim" idee komt: genoemde RFC waarschuwt er (bovenaan pagina 17) voor dat wachtwoorden over het algemeen te weinig entropie bevatten om veilig als PSK te kunnen worden gebruikt.
Voor het bezoeken van wilkekeurige websites is zo'n PSK natuurlijk niet praktisch, maar wel voor point-to-point verbindingen. Bijv. stunnel ondersteunt PSK (zie https://www.stunnel.org/auth.html).
Kortom, TLS is niet in alle scenario's kwetsbaar voor quantum computers; als je PSK's gebruikt en sterkere hashes + sterkere symmetrische ciphers inzet is TLS waarschijnlijk quantum-proof. DHE en digitale certificaten zoals wij ze nu kennen worden waarschijnlijk wel onbruikbaar door quantum computers, dus daar zullen we wel wat anders voor moeten verzinnen.
Door Anoniem: TLS zal kwetsbaar zijn vanwege het stuk asymmetriche encryptie dat in de huidige TLS protocollen zit:
Waarschijnlijk niet als je TLS zonder asymmetrische cryptografie gebruikt, en dat kan in een deel van de gevallen. Ik probeer dit toe te lichten.Versleutelen is zinloos als je niet weet met wie je communiceert; in elk geval de server zal zich moeten authenticeren (bewijzen dat hij is wie hij zegt dat hij is). Dat kan op twee manieren:
A) M.b.v. asymmetrische encryptie: de client krijgt de public key van de server (meestal in een digitaal certificaat dat meestal is ondertekend door een trusted third party) waarbij de server bewijst over de bijbehorende private key te beschikken (zonder die private key prijs te geven);
B) Middels een shared secret, ook bekend als PSK (Pre-Shared Key). In dit geval moet die PSK natuurlijk vooraf, via een ander kanaal, veilig zijn uitgewisseld. Als zowel client als server die PSK als sessiesleutel gebruiken (en die PSK niet gelekt is) weten beide partijen van elkaar wie zij zijn, nl. als ontvangen versleutelde data geen semi-random meuk bevat na ontsleutelen. Nb. PSK kost minder rekenkracht en is daarmee ook geschikt voor kleinere IoT devices.
M.b.t. methode A: aanvankelijk (vele jaren geleden gebruikelijk) genereerde de client een random sessie-sleutel, versleutelde deze met de public key van de server en stuurde het resultaat naar de server. Omdat (als het goed is) alleen de server over de bijpassende private key beschikt, kan alleen de server dat resultaat ontsleutelen, waarna beide partijen over de (symmetrische) sessiesleutel beschikken waar de verbinding vervolgens mee wordt versleuteld. Het is al vele jaren gebruikelijk om dit anders te doen: middels een Diffie-Hellman key agreement (dit wordt meestal een "exchange", DHE, genoemd - maar dat is het niet echt) wordt een sessiesleutel via een soort asymmetrische encryptie overeengekomen. Ter authenticatie ondertekent de server bepaalde parameters met diens private key; doordat de client die signature checkt a.d.h.v. de public key (meestal in een certificaat) authenticeert de server zich. Zowel DHE als het sleutelpaar dat gebruikt wordt voor authenticatie zijn naar verwachting kraakbaar door quantum computers.
Uit https://datatracker.ietf.org/doc/html/rfc8446 (de cijfers heb ik ervoor gezet):
The Transport Layer Security (TLS) Protocol Version 1.3
[...]
TLS supports three basic key exchange modes:
1) (EC)DHE (Diffie-Hellman over either finite fields or elliptic curves)
2) PSK-only
3) PSK with (EC)DHE
[...]
[...]
TLS supports three basic key exchange modes:
1) (EC)DHE (Diffie-Hellman over either finite fields or elliptic curves)
2) PSK-only
3) PSK with (EC)DHE
[...]
Als de PSK in mode 2 "out of band" (via een separaat veilig kanaal) wordt uitgewisseld, is er geen sprake meer van asymmetrische encryptie. In mode 3 (PSK with (EC)DHE) heb je het beste van beide werelden: de sessiesleutel ontstaat dan uit een HMAC (vereenvoudigd een hash van twee achter elkaar geplakte getallen) van de PSK en een via Diffie-Hellman overeengekomen secret. Daarmee heb je in elk geval forward secrecy tot een quantum-computer DH kraakt (dat moet dan wel per sessie). Maar zelfs dan valt de schade mee, de aanvaller kent dan het voor die sessie overeengekomen DH-secret (wat dan niet secret meer is); effectief is dit mechanisme dan gedegradeerd tot een random getal dat plain text naar de andere partij wordt gestuurd. Bij een voldoende sterke HMAC is de sessie-sleutel toch elke sessie anders (forward secrecy) en is het voor een MitM (Man in the Middle) nagenoeg onmogelijk om de PSK te achterhalen.
Voordat iemand op een "slim" idee komt: genoemde RFC waarschuwt er (bovenaan pagina 17) voor dat wachtwoorden over het algemeen te weinig entropie bevatten om veilig als PSK te kunnen worden gebruikt.
Voor het bezoeken van wilkekeurige websites is zo'n PSK natuurlijk niet praktisch, maar wel voor point-to-point verbindingen. Bijv. stunnel ondersteunt PSK (zie https://www.stunnel.org/auth.html).
Kortom, TLS is niet in alle scenario's kwetsbaar voor quantum computers; als je PSK's gebruikt en sterkere hashes + sterkere symmetrische ciphers inzet is TLS waarschijnlijk quantum-proof. DHE en digitale certificaten zoals wij ze nu kennen worden waarschijnlijk wel onbruikbaar door quantum computers, dus daar zullen we wel wat anders voor moeten verzinnen.
Bedankt Erik voor deze uiteenzetting. Het wordt meestal TLS-PSK genoemd.
TLS-PSK lijkt het meest geschikt te zijn voor IoT apparaten die veilig met elkaar moeten communiceren.
(echter TLS met asymmetrische encryptie is het meest gebruikelijk in ons dagelijks internetverkeer)
Bijv. 2 apparaten waarvan de bedoeling is dat ze over internet met elkaar gaan communiceren met de juiste PSK voorprogrammeren in een speciale chip zodat niemand er ongeauthorieerd bij kan, en vervolgens deze apparaten naar hun locaties sturen. De PSK hoeft dan niet over de lijn.
Immers als een PSK via een attackable medium moet worden gecommuniceerd, is het alweer lastig om alle risico's uit te sluiten, zoals we bijv. wel hebben gezien bij WPA-PSK (weliswaar geen TLS, maar het gaat hier over het met elkaar overeenkomen van een PSK) waar de PSK moet worden overeengekomen via het medium van de ether.
Misschien interessant:
https://blog.irdeto.com/software-protection/quantum-computing-message-security-and-white-box-cryptography/
TLS-PSK: Such solutions seem best suited for use in IoT and other solutions where machines are interacting with each other.
16-05-2021, 23:41 door
Erik van Straten
@Anoniem 15:06: dank voor de aanvullingen!
Met TLS v1.3 is er nogal wat veranderd m.b.t. PSK; er bestaan geen "TLS_PSK_*" cipher suites meer. Ook zie ik "TLS-PSK" niet terugkomen in https://datatracker.ietf.org/doc/html/rfc8446. Het zou mij niet verbazen als de term "TLS-PSK" komt te vervallen omdat PSK sinds 1.3 integraal onderdeel uitmaakt van TLS. Nb. https://en.wikipedia.org/wiki/TLS-PSK lijkt niet meer up-to-date doordat deze (nog) niet verwijst naar TLS v1.3.
Met TLS v1.3 is er nogal wat veranderd m.b.t. PSK; er bestaan geen "TLS_PSK_*" cipher suites meer. Ook zie ik "TLS-PSK" niet terugkomen in https://datatracker.ietf.org/doc/html/rfc8446. Het zou mij niet verbazen als de term "TLS-PSK" komt te vervallen omdat PSK sinds 1.3 integraal onderdeel uitmaakt van TLS. Nb. https://en.wikipedia.org/wiki/TLS-PSK lijkt niet meer up-to-date doordat deze (nog) niet verwijst naar TLS v1.3.
Door Erik van Straten: @Anoniem 15:06: dank voor de aanvullingen!
Met TLS v1.3 is er nogal wat veranderd m.b.t. PSK; er bestaan geen "TLS_PSK_*" cipher suites meer. Ook zie ik "TLS-PSK" niet terugkomen in https://datatracker.ietf.org/doc/html/rfc8446. Het zou mij niet verbazen als de term "TLS-PSK" komt te vervallen omdat PSK sinds 1.3 integraal onderdeel uitmaakt van TLS. Nb. https://en.wikipedia.org/wiki/TLS-PSK lijkt niet meer up-to-date doordat deze (nog) niet verwijst naar TLS v1.3.
Met TLS v1.3 is er nogal wat veranderd m.b.t. PSK; er bestaan geen "TLS_PSK_*" cipher suites meer. Ook zie ik "TLS-PSK" niet terugkomen in https://datatracker.ietf.org/doc/html/rfc8446. Het zou mij niet verbazen als de term "TLS-PSK" komt te vervallen omdat PSK sinds 1.3 integraal onderdeel uitmaakt van TLS. Nb. https://en.wikipedia.org/wiki/TLS-PSK lijkt niet meer up-to-date doordat deze (nog) niet verwijst naar TLS v1.3.
Je hebt gelijk. (https://datatracker.ietf.org/doc/html/rfc8446#section-2.2)
thanks!
Ik ga dit topic een schopje geven door te linken naar een recente blogpost over de 'controverse' rondom hydride contructies. Dat zijn constructies waarbij klassieke cryptografie (zoals RSA) gecombineerd wordt met post-quantum cryptografie. https://soatok.blog/2022/01/27/the-controversy-surrounding-hybrid-cryptography/
Als herinnering: de NSA lijkt sterk de voorkeur uit te spreken voor Post-Quantum-only cryptografie, terwijl er door grote commerciele partijen (o.a. Google en Cloudflare) maar ook de AIVD/BVD wordt gekeken naar hybride constructies.
Terwijl de klok door tikt, is het dus nog steeds geen uitgemaakte zaak op welke constructies we eigenlijk moeten overstappen...
Als herinnering: de NSA lijkt sterk de voorkeur uit te spreken voor Post-Quantum-only cryptografie, terwijl er door grote commerciele partijen (o.a. Google en Cloudflare) maar ook de AIVD/BVD wordt gekeken naar hybride constructies.
Terwijl de klok door tikt, is het dus nog steeds geen uitgemaakte zaak op welke constructies we eigenlijk moeten overstappen...
Maar op welke manier kunnen we ons nog enigszins beveiligen tot het schoudersurfen van morgen door Big Brother?
Ungoogled browser drivers, "go with the flow" zo veel als mogelijk is. Obfuscatie-manieren om met tor onder de radar the blijven. Consent weigeren. Wat is de beste weg?
luntrus
Ungoogled browser drivers, "go with the flow" zo veel als mogelijk is. Obfuscatie-manieren om met tor onder de radar the blijven. Consent weigeren. Wat is de beste weg?
luntrus
Er is op dit moment al asymmetrische versleuteling welke Quantum computer proof is, zie bijvoorbeeld https://www.cyberhelden.nl/episodes/episode-20/
De huidige universiteitsstandaard gebaseerd op symmetrische AES versleuteling voor vetrouwelijke uitwisseling van informatie is ook Quantum computer proof wanneer je een wachtwoord gebruikt met een entropie >= 256 bits.
Je kunt zo'n wachtwoord bijvoorbeeld genereren met een quantum random generator, zie https://www.cyberhelden.nl/episodes/episode-23/
De huidige universiteitsstandaard gebaseerd op symmetrische AES versleuteling voor vetrouwelijke uitwisseling van informatie is ook Quantum computer proof wanneer je een wachtwoord gebruikt met een entropie >= 256 bits.
Je kunt zo'n wachtwoord bijvoorbeeld genereren met een quantum random generator, zie https://www.cyberhelden.nl/episodes/episode-23/
30-01-2022, 17:52 door
Erik van Straten
Door Anoniem: Ik ga dit topic een schopje geven door te linken naar een recente blogpost over de 'controverse' rondom hydride contructies. Dat zijn constructies waarbij klassieke cryptografie (zoals RSA) gecombineerd wordt met post-quantum cryptografie. https://soatok.blog/2022/01/27/the-controversy-surrounding-hybrid-cryptography/
[...]
Uit laatstgenoemde pagina:[...]
1. Require separate classical signatures and post-quantum signatures.
2. Specify a composite mode that combines the two together and treat it as a distinct algorithm.
Mijn eerste gedachte bij punt 1 is: wat doe je als één van de twee signatures niet klopt?2. Specify a composite mode that combines the two together and treat it as a distinct algorithm.
En als punt 2 zo'n situatie voorkomt, betekent dit dan dat de hele signature als ongeldig wordt beschouwd als één van de twee niet (meer) klopt?
Met helikopterview: is "hybrid", bij cryptography, the best of juist the worst of both worlds? Mijn onderbuik zegt het laatste; extra complexiteit is zelden verstandig. Eerst zien, dan geloven.
Leuk, al die discussies over hoe je op moet letten of over X jaar je data leesbaar wordt. Maar wat ik tijdens mijn diensttijd geleerd heb, is dat het meest essentiële aan versleutelen van informatie is, of de tijd om de informatie te ontsleutelen langer of korter is, dan dat de inhoud van die data nog nuttig is. Een bericht waarbij een aanval op een stelling wordt voorbereid, hoeft niet langer veilig te zijn, dan tot nadat die aanval gebeurd is. Heb je zaken die "eeuwig" versleuteld moeten zijn, dan wens ik je sowieso succes, want dat soort data kun je beter ergens opslaan, off-line en niet toegankelijk voor wie dan ook.
Door Anoniem: Leuk, al die discussies over hoe je op moet letten of over X jaar je data leesbaar wordt. Maar wat ik tijdens mijn diensttijd geleerd heb, is dat het meest essentiële aan versleutelen van informatie is, of de tijd om de informatie te ontsleutelen langer of korter is, dan dat de inhoud van die data nog nuttig is. [...]
Klopt, het aantal soorten van informatie waarbij het heel lang essentieel is dat deze geheim blijft, is beperkt. Maar deze bestaan wel, denk aan medische gegevens.Vooral defensie zal ervan uit moeten gaan dat informatie, vroeger of later, uitlekt (niet noodzakelijkerwijs doordat encryptie wordt gebroken, maar bijvoorbeeld doordat een JSF doorschiet bij de landing op een vliegdekschip en in de Chinese zee belandt).
Daarbij: de laatste decennia hebben we (door schade en schande) ingezien dat de authenticiteit van informatie in veel gevallen belangrijker is dan vertrouwelijkheid - maar veel mensen zien dat nog niet in.
Het is bijvoorbeeld een wijdverbreid misverstand dat encryptie het enige doel was van de transitie http -> https (gevoed door belachelijk succesvolle initiatieven als Let's Encrypt): voordat het verstandig is om versleutelde vertrouwelijke informatie uit te wisselen, moet je namelijk weten met precies met wie je de versleutelde informatie en de sleutel uitwisselt. Immers, als je dat niet precies weet, kun je die versleutelde informatie net zo goed, met de sleutel erbij, op straat gooien.
Digitale handtekeningen en secure key agreements of -exchanges zijn minstens net zo belangrijke cryptografische bouwstenen als encryptie (dat sowieso deels niet het probleem is bij QC, want daar we hebben redelijke symmetrische algoritmes voor).
Bijvoorbeeld bij contracten kan het essentieel zijn dat digitale handtekeningen vele jaren "onkraakbaar" blijven.
Ben je soms vergeten dat Whatsapp pas sinds 2016 +- is begonnen met E2E. Ik weet vrijwel zeker dat jij dat ook gebruikt.
En dan heb je nog MSN-messenger etc. allemaal databanken met onversleutelde gesprekken, maar ik heb nog niets gezien.
SMS is ook onversleuteld. Die liggen ook niet op straat.
En dan heb je nog MSN-messenger etc. allemaal databanken met onversleutelde gesprekken, maar ik heb nog niets gezien.
SMS is ook onversleuteld. Die liggen ook niet op straat.
Op https://www.ndax.eu/tQ-KKEqK_QHenasPfSqq.pdf is de huidige universiteitsstandaard voor uitwisseling van vertrouwelijke informatie te vinden.
Deze standaard kan online en offline gebruikt worden.
Als de standaard offline gebruikt wordt en de versleutelde data op een MicroSD via de reguliere post verstuurd wordt dan kan de informatie uitwisseling veilig en anoniem.
Wanneer er passwords worden gebruikt met een entropie > 256 bits, zie https://www.math4sci.com/randomness-in-science-and-philisophy/ dan is ook met een toekomstige Quantum Computer de versleuteling niet te kraken.
Deze standaard kan online en offline gebruikt worden.
Als de standaard offline gebruikt wordt en de versleutelde data op een MicroSD via de reguliere post verstuurd wordt dan kan de informatie uitwisseling veilig en anoniem.
Wanneer er passwords worden gebruikt met een entropie > 256 bits, zie https://www.math4sci.com/randomness-in-science-and-philisophy/ dan is ook met een toekomstige Quantum Computer de versleuteling niet te kraken.
In deze discussie is Mosca's theorem belangrijk, zie https://www.ndax.eu/8EwlkHHv+2PwtZpuiS-L.pdf
Mosca's Theorem: ALS x + y > z DAN is er een probleem.
Hierin is:
x = Security Shelf Life
y = Migration Time
z = Time to compromise
Mosca's Theorem: ALS x + y > z DAN is er een probleem.
Hierin is:
x = Security Shelf Life
y = Migration Time
z = Time to compromise
Door Anoniem: In deze discussie is Mosca's theorem belangrijk, zie https://www.ndax.eu/8EwlkHHv+2PwtZpuiS-L.pdf
Mosca's Theorem: ALS x + y > z DAN is er een probleem.
Hierin is:
x = Security Shelf Life
y = Migration Time
z = Time to compromise
Mosca's Theorem: ALS x + y > z DAN is er een probleem.
Hierin is:
x = Security Shelf Life
y = Migration Time
z = Time to compromise
Ja, klinkt exact. Helaas is het heel dikke koffiedik om iets te schatten over de relevante parameters x/y/z .
Doet denken aan Drake's equation over buitenaards leven - ook die parameters hebben waanzinnige marges.
En trouwens ook veel business plannen en andere economie - formule is prima, maar de cruciale data zijn vaak natte vinger werk.
Het gebrek aan concrete resultaten van QC maakt de hype wat onbetrouwbaar.
Als we het artikel lezen dan kunnen we als voorbeeld nemen:
x = 20 jaar
y = 15 jaar
z = 15 jaar (met waarschijnlijkheid = 1/2)
Conform Mosca's theorem is 20 + 15 > 15 en hebben we dus op dit moment een probleem.
x = 20 jaar
y = 15 jaar
z = 15 jaar (met waarschijnlijkheid = 1/2)
Conform Mosca's theorem is 20 + 15 > 15 en hebben we dus op dit moment een probleem.
Door Anoniem: Als we het artikel lezen dan kunnen we als voorbeeld nemen:
x = 20 jaar
y = 15 jaar
z = 15 jaar (met waarschijnlijkheid = 1/2)
Conform Mosca's theorem is 20 + 15 > 15 en hebben we dus op dit moment een probleem.
x = 20 jaar
y = 15 jaar
z = 15 jaar (met waarschijnlijkheid = 1/2)
Conform Mosca's theorem is 20 + 15 > 15 en hebben we dus op dit moment een probleem.
Op https://bit.ly/35F3FyN kun je een handleiding vinden welke stappen je kunt doorlopen om te checken welke post-quantum kwetsbaarheden je hebt als organisatie en wat je eraan kunt doen.
03-03-2022, 11:56 door
Overcome
Door Anoniem: ...
Op https://bit.ly/35F3FyN kun je een handleiding vinden welke stappen je kunt doorlopen om te checken welke post-quantum kwetsbaarheden je hebt als organisatie en wat je eraan kunt doen.
Op https://bit.ly/35F3FyN kun je een handleiding vinden welke stappen je kunt doorlopen om te checken welke post-quantum kwetsbaarheden je hebt als organisatie en wat je eraan kunt doen.
Op een security forum zou je geen URL afkorters moeten gebruiken als dat niet strikt noodzakelijk is. Voor iedereen die wil weten naar welke URL wordt verwezen: zet een plusje ('+') achter de Bit.ly URL en plaats de URL in de adresbalk van je browser. Je krijgt dan een preview van de URL te zien. Je ziet dan ook dat de URL naar ndax.eu verwijst, een domeinnaam die al vaker naar voren is gekomen op deze site en die gekenmerkt kan worden door spam en clickbait, ook doordat de plaatser van de berichten om de zoveel tijd dezelfde tekst neerplempt over een universiteitsstandaard voor data-uitwisseling (die niet bestaat), bestanden offline versturen via een microSD kaartje etc. Ook in dit geval betreft het een PDF bestand dat gejat is van https://www.optoscience.com/maker/id/pdf/quantum-proofing_your_organisation.pdf en waar de nodige pagina's over het bedrijf zelf uit zijn gehaald. Zie je "ndax.eu", ben dan vooral op je hoede.
Door Anoniem:
Op https://bit.ly/35F3FyN kun je een handleiding vinden welke stappen je kunt doorlopen om te checken welke post-quantum kwetsbaarheden je hebt als organisatie en wat je eraan kunt doen.
Door Anoniem: Als we het artikel lezen dan kunnen we als voorbeeld nemen:
x = 20 jaar
y = 15 jaar
z = 15 jaar (met waarschijnlijkheid = 1/2)
Conform Mosca's theorem is 20 + 15 > 15 en hebben we dus op dit moment een probleem.
x = 20 jaar
y = 15 jaar
z = 15 jaar (met waarschijnlijkheid = 1/2)
Conform Mosca's theorem is 20 + 15 > 15 en hebben we dus op dit moment een probleem.
Op https://bit.ly/35F3FyN kun je een handleiding vinden welke stappen je kunt doorlopen om te checken welke post-quantum kwetsbaarheden je hebt als organisatie en wat je eraan kunt doen.
Waarom gebruik je zo'n klotige URL verkorter ? Je zit hier niet op twitter .
De url is overigens https://www.ndax.eu/H-P0cSQlBY1sh1GQJhSS.pdf
(het ligt bijna voor de vingers om een stel NSFW urls te verkorten , gewoon om even te laten zien waarom het zo irritant is)
Dat paper staat ongeveer niks in , trouwens - buiten reclame van de "partners" die graag consultancy willen verkopen .
QC is nou typisch is om gezellig aan de koffie automaat over te leuteren , of op de vrijmibo . Je werktijd moet je vooral besteden aan de concrete en acute dreiging van vandaag .
Die hype machine die nu al 15 jaar zegt "binnen 10 jaar" is een mooie bezigheid voor researchers , maar levert nog steeds niks op .
Tip voor iedereen : zoek eens op hoe groot de getallen zijn die tussen 1994 en nu met behulp van een quantum computer ontbonden zijn.
Door Overcome:
Op een security forum zou je geen URL afkorters moeten gebruiken als dat niet strikt noodzakelijk is. Voor iedereen die wil weten naar welke URL wordt verwezen: zet een plusje ('+') achter de Bit.ly URL en plaats de URL in de adresbalk van je browser. Je krijgt dan een preview van de URL te zien. Je ziet dan ook dat de URL naar ndax.eu verwijst, een domeinnaam die al vaker naar voren is gekomen op deze site en die gekenmerkt kan worden door spam en clickbait, ook doordat de plaatser van de berichten om de zoveel tijd dezelfde tekst neerplempt over een universiteitsstandaard voor data-uitwisseling (die niet bestaat), bestanden offline versturen via een microSD kaartje etc. Ook in dit geval betreft het een PDF bestand dat gejat is van https://www.optoscience.com/maker/id/pdf/quantum-proofing_your_organisation.pdf en waar de nodige pagina's over het bedrijf zelf uit zijn gehaald. Zie je "ndax.eu", ben dan vooral op je hoede.
Door Anoniem: ...
Op https://bit.ly/35F3FyN kun je een handleiding vinden welke stappen je kunt doorlopen om te checken welke post-quantum kwetsbaarheden je hebt als organisatie en wat je eraan kunt doen.
Op https://bit.ly/35F3FyN kun je een handleiding vinden welke stappen je kunt doorlopen om te checken welke post-quantum kwetsbaarheden je hebt als organisatie en wat je eraan kunt doen.
Op een security forum zou je geen URL afkorters moeten gebruiken als dat niet strikt noodzakelijk is. Voor iedereen die wil weten naar welke URL wordt verwezen: zet een plusje ('+') achter de Bit.ly URL en plaats de URL in de adresbalk van je browser. Je krijgt dan een preview van de URL te zien. Je ziet dan ook dat de URL naar ndax.eu verwijst, een domeinnaam die al vaker naar voren is gekomen op deze site en die gekenmerkt kan worden door spam en clickbait, ook doordat de plaatser van de berichten om de zoveel tijd dezelfde tekst neerplempt over een universiteitsstandaard voor data-uitwisseling (die niet bestaat), bestanden offline versturen via een microSD kaartje etc. Ook in dit geval betreft het een PDF bestand dat gejat is van https://www.optoscience.com/maker/id/pdf/quantum-proofing_your_organisation.pdf en waar de nodige pagina's over het bedrijf zelf uit zijn gehaald. Zie je "ndax.eu", ben dan vooral op je hoede.
We hebben de informatie van de ndax.eu links gecontroleerd en de gegeven informatie klopt. Bijvoorbeeld de universiteitsstandaard (waarvan hierboven geclaimd is dat deze niet bestaat) kun je bekijken op:
https://www.ru.nl/ict/algemeen/informatie-beveiligen/informatiebeveiliging/bestanden-versleutelen/7zip-aes/
Door Anoniem:
We hebben de informatie van de ndax.eu links gecontroleerd en de gegeven informatie klopt. Bijvoorbeeld de universiteitsstandaard (waarvan hierboven geclaimd is dat deze niet bestaat) kun je bekijken op:
https://www.ru.nl/ict/algemeen/informatie-beveiligen/informatiebeveiliging/bestanden-versleutelen/7zip-aes/
Door Overcome:
Op een security forum zou je geen URL afkorters moeten gebruiken als dat niet strikt noodzakelijk is. Voor iedereen die wil weten naar welke URL wordt verwezen: zet een plusje ('+') achter de Bit.ly URL en plaats de URL in de adresbalk van je browser. Je krijgt dan een preview van de URL te zien. Je ziet dan ook dat de URL naar ndax.eu verwijst, een domeinnaam die al vaker naar voren is gekomen op deze site en die gekenmerkt kan worden door spam en clickbait, ook doordat de plaatser van de berichten om de zoveel tijd dezelfde tekst neerplempt over een universiteitsstandaard voor data-uitwisseling (die niet bestaat), bestanden offline versturen via een microSD kaartje etc. Ook in dit geval betreft het een PDF bestand dat gejat is van https://www.optoscience.com/maker/id/pdf/quantum-proofing_your_organisation.pdf en waar de nodige pagina's over het bedrijf zelf uit zijn gehaald. Zie je "ndax.eu", ben dan vooral op je hoede.
Door Anoniem: ...
Op https://bit.ly/35F3FyN kun je een handleiding vinden welke stappen je kunt doorlopen om te checken welke post-quantum kwetsbaarheden je hebt als organisatie en wat je eraan kunt doen.
Op https://bit.ly/35F3FyN kun je een handleiding vinden welke stappen je kunt doorlopen om te checken welke post-quantum kwetsbaarheden je hebt als organisatie en wat je eraan kunt doen.
Op een security forum zou je geen URL afkorters moeten gebruiken als dat niet strikt noodzakelijk is. Voor iedereen die wil weten naar welke URL wordt verwezen: zet een plusje ('+') achter de Bit.ly URL en plaats de URL in de adresbalk van je browser. Je krijgt dan een preview van de URL te zien. Je ziet dan ook dat de URL naar ndax.eu verwijst, een domeinnaam die al vaker naar voren is gekomen op deze site en die gekenmerkt kan worden door spam en clickbait, ook doordat de plaatser van de berichten om de zoveel tijd dezelfde tekst neerplempt over een universiteitsstandaard voor data-uitwisseling (die niet bestaat), bestanden offline versturen via een microSD kaartje etc. Ook in dit geval betreft het een PDF bestand dat gejat is van https://www.optoscience.com/maker/id/pdf/quantum-proofing_your_organisation.pdf en waar de nodige pagina's over het bedrijf zelf uit zijn gehaald. Zie je "ndax.eu", ben dan vooral op je hoede.
We hebben de informatie van de ndax.eu links gecontroleerd en de gegeven informatie klopt. Bijvoorbeeld de universiteitsstandaard (waarvan hierboven geclaimd is dat deze niet bestaat) kun je bekijken op:
https://www.ru.nl/ict/algemeen/informatie-beveiligen/informatiebeveiliging/bestanden-versleutelen/7zip-aes/
Een "_universiteitsstandaard_" is heel wat anders dan het advies van de IT afdeling van een universiteit .
Moet dat werkelijk uitgelegd worden ?
(advies van die ru.nl link is op zich prima, daar niet van )
Door Overcome:
Op een security forum zou je geen URL afkorters moeten gebruiken als dat niet strikt noodzakelijk is. Voor iedereen die wil weten naar welke URL wordt verwezen: zet een plusje ('+') achter de Bit.ly URL en plaats de URL in de adresbalk van je browser. Je krijgt dan een preview van de URL te zien. Je ziet dan ook dat de URL naar ndax.eu verwijst, een domeinnaam die al vaker naar voren is gekomen op deze site en die gekenmerkt kan worden door spam en clickbait, ook doordat de plaatser van de berichten om de zoveel tijd dezelfde tekst neerplempt over een universiteitsstandaard voor data-uitwisseling (die niet bestaat), bestanden offline versturen via een microSD kaartje etc. Ook in dit geval betreft het een PDF bestand dat gejat is van https://www.optoscience.com/maker/id/pdf/quantum-proofing_your_organisation.pdf en waar de nodige pagina's over het bedrijf zelf uit zijn gehaald. Zie je "ndax.eu", ben dan vooral op je hoede.
Door Anoniem: ...
Op https://bit.ly/35F3FyN kun je een handleiding vinden welke stappen je kunt doorlopen om te checken welke post-quantum kwetsbaarheden je hebt als organisatie en wat je eraan kunt doen.
Op https://bit.ly/35F3FyN kun je een handleiding vinden welke stappen je kunt doorlopen om te checken welke post-quantum kwetsbaarheden je hebt als organisatie en wat je eraan kunt doen.
Op een security forum zou je geen URL afkorters moeten gebruiken als dat niet strikt noodzakelijk is. Voor iedereen die wil weten naar welke URL wordt verwezen: zet een plusje ('+') achter de Bit.ly URL en plaats de URL in de adresbalk van je browser. Je krijgt dan een preview van de URL te zien. Je ziet dan ook dat de URL naar ndax.eu verwijst, een domeinnaam die al vaker naar voren is gekomen op deze site en die gekenmerkt kan worden door spam en clickbait, ook doordat de plaatser van de berichten om de zoveel tijd dezelfde tekst neerplempt over een universiteitsstandaard voor data-uitwisseling (die niet bestaat), bestanden offline versturen via een microSD kaartje etc. Ook in dit geval betreft het een PDF bestand dat gejat is van https://www.optoscience.com/maker/id/pdf/quantum-proofing_your_organisation.pdf en waar de nodige pagina's over het bedrijf zelf uit zijn gehaald. Zie je "ndax.eu", ben dan vooral op je hoede.
Wanneer je bijvoorbeeld artikel 3.9 "Toegang voor autoriteiten" leest op https://docplayer.nl/2024894-Surfdrive-service-level-specificatie.html dan lees je dat "Indien autoriteiten recht hebben op toegang tot data, zal deze data via een offline
medium aan de autoriteiten ter beschikking worden gesteld".
Dus het klopt wat "ndax.eu" stelt over versleutelde bestanden versturen op een offline medium.
Door Anoniem:
Door Anoniem:
Er is GEEN ENKEL zicht op het maken van een quantum computer om AES te kraken,
Er is GEEN ENKEL zicht op het maken van een quantum computer om AES te kraken,
Dat zal ook komen omdat AES noet zo gevoelig is voor quantumcomputers, die maken decryptie hooguit een factor sqrt() sneller, wat het in de praktijk nog steeds onmogelijk maakt.
Quantumcomputers zijn wel potentieel gevaarlijk voor de nu gebruikte public key algorithmes zoals RSA, El Gamal en Elliptic curves. Maar gelukkig bestaan er al hiervoor vervangers die ook geen last van quantumcomputers hebben. ze zijn momenteel alleen nog niet zo handig in het gebruik (erg grote keylangtes) mar de hardware verbetert vanzelf en dit probleem is niet zo nijpend. Ze zouden nu al ingezet kunnen worden. Zie https://en.wikipedia.org/wiki/Post-quantum_cryptography.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Information Security Officer (2fte)
Een uitdagende rol waarbij jij, op basis van security, de vertaalslag maakt tussen business en IT en direct bijdraagt aan de veiligheid van informatie binnen de gemeente Almere. Dat is in een notendop waar jij als Information Security Officer mee bezig bent. Interesse gewekt? Door groei van de organisatie zijn we op zoek naar twee nieuwe collega’s.
Specialiseer je in Forensisch ICT
Online informatieavond 19 november
Wil jij je specialiseren in digitaal forensisch onderzoek? Je kennis verbreden en tech-nische vaardigheden ontwikkelen? Ontdek de cursus- en opleidingsmogelijkheden van Hogeschool Leiden:
- Bachelor Informatica Forensisch ICT (deeltijd)
- Master Digital Forensics (vol- en deeltijd)
- Module Mobile Forensics
- Module Data Analytics
Interesse? Meld je aan!
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
