#quantique #cryptographie #PQC
J'apprends le terme de Q-day, qui désigne le jour où un CRQC (Cryptographically Relevant Quantum Computer, prononcer "cric") cassera tout. Le Q-day, selon les meilleurs experts, est entre deux et cent ans dans le futur.
C'est même déjà dans Wikipédia anglophone https://en.wikipedia.org/wiki/Q-Day
This is undoubtedly the most promising Post-Quantum TLS deployment situation I have seen for #Tor since we started discussing it more actively in the team. Very exciting!
I hope that OpenSSL 3.5, when released, will make it into #Debian Trixie. That would make deployment of this so much more snappy and easy for the Tor network to upgrade, but that may be dreaming. The timelines here look quite difficult for that to happen, but let's hope.
Lo and behold, #OpenSSL 3.5 (their upcoming LTS release) will come out here at the beginning of April, and it does indeed support some of these hybrid PQC schemes. Their recent beta2 announcement can be read here: https://openssl-library.org/post/2025-03-25-openssl-3.5-beta/ and their roadmap is at https://openssl-library.org/roadmap/index.html
Very excited by this work. Big kudos to the OpenSSL Team here! 
Already planning on giving this a spin with the C implementation of #Tor later this week to see how it goes!
This Venn diagram showing which PQ algorithms are permitted by which government regulatory body from Mike Ounsworth's presentation at the Real World Post-Quantum Cryptography Workshop last week.
(Mike gave a version of that talk earlier this year at the PKIC conf: https://pkic.org/events/2025/pqc-conference-austin-us/WED_BREAKOUT_1200_Mike-Ounsworth_Architecting-PKI-Hierarchies-for-Graceful-PQ-Migration.pdf)
Post-Quantum #DNSSEC Testbed with BIND and PowerDNS
The NCSC’s advisory deadline of 2035 for organisations to introduce quantum-safe algorithms is too late, according to some industry insiders.
The NCSC’s advisory deadline of 2035 for organisations to introduce quantum-safe algorithms is too late, according to some industry insiders.
…ja und nein und vor allem ist es Marketing durch Angstmacherei. Quantenkomputer sind noch nicht wirklich einsetzbar obwohl es viele als solches gerne vermarkten.
»Quantenschlüssel aus der Sicht des CISO:
Quantentechnologien – ein Sicherheitsrisiko oder das Mittel der Wahl gegen Cyberangriffe? Warum, für wen und wo es wichtig ist, die Integration von Quantentechnologien zu starten.«
https://www.csoonline.com/article/3846875/quantenschlussel-aus-der-sicht-des-ciso.html
»The Quantum Apocalypse Is Coming. Be Very Afraid:
What happens when quantum computers can finally crack encryption and break into the world’s best-kept secrets? It’s called Q-Day—the worst holiday maybe ever.«
Since this is very much for us, I cannot deny it, but I see it as a marketing propaganda. To scare is also a marketing strategy.
https://www.wired.com/story/q-day-apocalypse-quantum-computers-encryption/
Out of the top 100K domains, roughly 28K negotiate a quantum safe key exchange.
Almost all of those support both x25519_kyber768 and X25519MLKEM758; only 129 sites support SecP256r1MLKEM768. There are _no_ sites that support pure #PQC via e.g., mlkem768.
The overwhelming majority of sites that support PQC do so by way of Cloudflare. That percentage matches Cloudflare's overall coverage of the top 1M domains.
Just in time for Real World PQC Workshop:
I took at a look at who currently supports #PQC. The answer will not surprise you at all.
…neben dem vorhin erwähnten Marketing bezüglich des Post-Quantom Kryptografie ist darauf hin auch wieder die Angsmacherei davon. Das die mal angewendet wird ist klar aber wie ist die Frage.
»Ihre Passwörter sind bald wertlos: Quantencomputer knacken alles!
Quantencomputer revolutionieren die Rechenleistung. Sie lösen hochkomplexe Aufgaben in Sekundenschnelle. Doch die Technologie birgt auch Gefahren.«
I have written a new white-paper for Far Phase, where I analysed the most popular Australian banking websites (18 in all) and found that **none** of them protected people from quantum threats. This is despite bank interactions being 99% via websites and apps, and banks holding some of the most sensitive, long-lived data. Yet, nearly 40% of global secure web traffic is protected from quantum threats, and even the Google search engine offers this protection. Australians would not expect that a search engine offers better post-quantum protection for their sensitive data than Australia's biggest banks. With technology enablers making this easier to implement in the next couple of months, Australian banks should urgently update their websites to protect their users.
https://farphase.com/white-paper-on-australian-banking-websites-and-pqc/
#quantum #pqc #australia #banking #cybersecurity #farphase #whitepaper
UK cybersecurity agency National Cyber Security Centre is recommending that organisations start replacing existing asymmetric public key cryptosystems with post-quantum cryptography (PQC) alternatives to defend themselves against quantum computers
"Time to be crypto* agile, not fragile." - good criticism of the IETF's slow move on post-quantum cryptography adoption. "Stop getting in the way of consensus."
https://datatracker.ietf.org/meeting/122/materials/slides-122-pquip-ietf-is-quantum-fragile-01.pdf
* "crypto" means cryptography; always has, always will
NIST selects HQC (Hamming Quasi-Cyclic -- https://pqc-hqc.org/) for standardization as the second #PQC key-encapsulation mechanism after ML-KEM.
But no rush, "the final version will be published in approximately two years".
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/w-6RREtb7-c/m/vRjBJE3dAAAJ
#OpenSSL will get the now standardized post-quantum cryptography algorithms (ML-KEM, ML-DSA, SLH-DSA) in 3.5 (planned release date is 2025-04-08):
https://openssl-library.org/post/2025-02-04-release-announcement-3.5/
This will include X25519MLKEM768, and will be enabled and preferred by default:
https://mailarchive.ietf.org/arch/msg/tls/g9sagkuAu8KlWpmJ30YdXbga5Xg/
Scientists create world's 1st chip that can protect data in the age of #QuantumComputing attacks
Looks like Google has enabled X25519MLKEM768 for Gmail STARTTLS:
```
$ openssl s_client -groups X25519MLKEM768 -starttls smtp -connect gmail-smtp-in.l.google.com.:25
Connecting to 2607:f8b0:4004:c07::1b
CONNECTED(00000005)
[…]
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
[…]
250 SMTPUTF8
```
Neat!
