#postquantum — Public Fediverse posts

Meet KEMchatka: an experimental, serverless P2P terminal chat over Tor hidden services.

No accounts, no port forwarding, zero disk logging.

​Features hybrid post-quantum encryption: X25519 + ML-KEM-1024 (FIPS 203) combined via HKDF-SHA512 to defeat "harvest now, decrypt later" attacks. Simple out-of-band setup.

​When privacy is under threat, build tools that protect it.

https://github.com/bashcore/kemchatka

​ #PostQuantum #Tor #Python #CyberSecurity #Privacy #OpenSource #Cryptography

Meet KEMchatka: an experimental, serverless P2P terminal chat over Tor hidden services.

No accounts, no port forwarding, zero disk logging.

​Features hybrid post-quantum encryption: X25519 + ML-KEM-1024 (FIPS 203) combined via HKDF-SHA512 to defeat "harvest now, decrypt later" attacks. Simple out-of-band setup.

​When privacy is under threat, build tools that protect it.

https://github.com/bashcore/kemchatka

​ #PostQuantum #Tor #Python #CyberSecurity #Privacy #OpenSource #Cryptography

The Ethereum Foundation is abandoning Poseidon for L1, pivoting to SHA or BLAKE. Justin Drake called it the end of an eight year, eight figure rabbit hole. I tried to understand what actually happened, and the short version is that nobody broke anything.

The Foundation paused its $992,000 Poseidon1 collision prize on August 1, twelve days before the announcement. Two years of funded cryptanalysis, roughly $1.36M in announced ceilings, produced exactly what such programs should. Reduced-round results, a partial collision tier claimed in April, and no break on any parameter set that matters.

What changed was the proving side. Binius at EUROCRYPT 2025 and then Flock this June made bit-oriented hashes cheap inside binary-field SNARKs. Flock proves 660k+ BLAKE3 compressions per second on ten M4 Max cores at under 250x native cost. Poseidon existed to make hashing affordable in prime-field circuits, and that problem dissolved.

Two details the coverage missed. Buterin publicly refused a Poseidon precompile in February. The program had found Poseidon2 issues needing extra rounds or a reversion to Poseidon1, and enshrining one version meant a dangling precompile forever. And Anthropic's July release, the one that broke HAWK, also pointed Mythos at Poseidon and got under 10x, a mildly reassuring data point almost nobody registered.

For this audience the RC4 parallel will make sense. AES-NI shipped in 2010, RC4 hung on through BEAST era workarounds, and RFC 7465 only killed it in 2015. Same shape here, except Ethereum's dependency was still in a research roadmap instead of a billion endpoints. The rest of us have the harder version.

Full analysis, including the four things the announcement doesn't say and the caveat that the binary-field provers doing this are young software. Full analysis:

https://postquantum.com/security-pqc/ethereum-roadmap-drops-poseidon/

#PostQuantum #Cryptography #Ethereum #PQC

The Ethereum Foundation is abandoning Poseidon for L1, pivoting to SHA or BLAKE. Justin Drake called it the end of an eight year, eight figure rabbit hole. I tried to understand what actually happened, and the short version is that nobody broke anything.

The Foundation paused its $992,000 Poseidon1 collision prize on August 1, twelve days before the announcement. Two years of funded cryptanalysis, roughly $1.36M in announced ceilings, produced exactly what such programs should. Reduced-round results, a partial collision tier claimed in April, and no break on any parameter set that matters.

What changed was the proving side. Binius at EUROCRYPT 2025 and then Flock this June made bit-oriented hashes cheap inside binary-field SNARKs. Flock proves 660k+ BLAKE3 compressions per second on ten M4 Max cores at under 250x native cost. Poseidon existed to make hashing affordable in prime-field circuits, and that problem dissolved.

Two details the coverage missed. Buterin publicly refused a Poseidon precompile in February. The program had found Poseidon2 issues needing extra rounds or a reversion to Poseidon1, and enshrining one version meant a dangling precompile forever. And Anthropic's July release, the one that broke HAWK, also pointed Mythos at Poseidon and got under 10x, a mildly reassuring data point almost nobody registered.

For this audience the RC4 parallel will make sense. AES-NI shipped in 2010, RC4 hung on through BEAST era workarounds, and RFC 7465 only killed it in 2015. Same shape here, except Ethereum's dependency was still in a research roadmap instead of a billion endpoints. The rest of us have the harder version.

Full analysis, including the four things the announcement doesn't say and the caveat that the binary-field provers doing this are young software. Full analysis:

https://postquantum.com/security-pqc/ethereum-roadmap-drops-poseidon/

#PostQuantum #Cryptography #Ethereum #PQC

Cryptanalysts are using AI models now, openly and on live claims. So what does "independently confirmed" mean? Less than it meant two years ago, and two events this summer show why.

April 2024 is the baseline. Yilei Chen posted a claimed polynomial-time quantum algorithm for LWE on the first day of the NIST PQC Standardization Conference. Eight days later he withdrew it, with an acknowledgment thanking Hongxun Wu and, independently, Thomas Vidick for finding the bug in Step 9. That parenthetical is the whole quality control mechanism of the field. Two experts, reasoning separately, converged on the same defect. Neither had seen the other's reading.

July 23, 2026. Ananth and Sahai at UCSB and UCLA posted a proof of efficient unclonable encryption at 10:35 Pacific. Seyoon Ragavan at MIT posted the same result three hours and eighteen minutes later. Both credited GPT-5.6 Sol Ultra with the core ideas. Both traced to the same Simons Institute talk. Neither knew the other was working on it. Ragavan drove the model in supervised two-hour stretches; Ananth and Sahai used a self-critiquing UCLA harness. Two workflows about as different as two workflows get, one construction, one working day.

August 2026. Daniel Simon's claimed polynomial-time algorithm for the Dihedral Coset Problem is being adjudicated right now on ePrint and Discord, in days rather than months, with Bernstein and Kirshanova among the people reading it. Several of the substantive responses were produced by humans working with models. One lists two language models on its byline. Disclosure across the documents is uneven: some name the model and version, some say only "AI assistance."

The mechanism cryptanalysis depends on is not expertise. It is decorrelated failure. Two humans with similar training still make different mistakes, at different points, for different reasons, and their errors decorrelate even when their education does not. The risk with shared tooling is not sampling correlation. It is common-cause error, where shared weights, training data, post-training and retrieval reproduce the same blind spot across operators who have no way of noticing they share it.

I am not claiming three model-assisted reviews reduce to one. I am claiming we currently lack the provenance to know how much independent weight they deserve.

The fix is cheap. Every cryptanalysis note that circulates before peer review should end with two sections: who found what, and what was checked by whom, with what, and how hard. Ragavan's paper already does most of it, and ships a Lean 4 formalization that states which claims it does not cover. A kernel shares no weights with anything.

IACR has barred models from bylines since May 2025. That rule governs formal submission. It does not reach the circulating notes where Simon is actually being adjudicated.

(This post was edited by AI, but the points are mine. If anyone else wrote the same thing around the same time, blame it on ChatGPT)

https://postquantum.com/post-quantum/independence-problem-ai-cryptanalysis/

#infosec #cryptography #cryptanalysis #PQC #postquantum #formalmethods

Cryptanalysts are using AI models now, openly and on live claims. So what does "independently confirmed" mean? Less than it meant two years ago, and two events this summer show why.

April 2024 is the baseline. Yilei Chen posted a claimed polynomial-time quantum algorithm for LWE on the first day of the NIST PQC Standardization Conference. Eight days later he withdrew it, with an acknowledgment thanking Hongxun Wu and, independently, Thomas Vidick for finding the bug in Step 9. That parenthetical is the whole quality control mechanism of the field. Two experts, reasoning separately, converged on the same defect. Neither had seen the other's reading.

July 23, 2026. Ananth and Sahai at UCSB and UCLA posted a proof of efficient unclonable encryption at 10:35 Pacific. Seyoon Ragavan at MIT posted the same result three hours and eighteen minutes later. Both credited GPT-5.6 Sol Ultra with the core ideas. Both traced to the same Simons Institute talk. Neither knew the other was working on it. Ragavan drove the model in supervised two-hour stretches; Ananth and Sahai used a self-critiquing UCLA harness. Two workflows about as different as two workflows get, one construction, one working day.

August 2026. Daniel Simon's claimed polynomial-time algorithm for the Dihedral Coset Problem is being adjudicated right now on ePrint and Discord, in days rather than months, with Bernstein and Kirshanova among the people reading it. Several of the substantive responses were produced by humans working with models. One lists two language models on its byline. Disclosure across the documents is uneven: some name the model and version, some say only "AI assistance."

The mechanism cryptanalysis depends on is not expertise. It is decorrelated failure. Two humans with similar training still make different mistakes, at different points, for different reasons, and their errors decorrelate even when their education does not. The risk with shared tooling is not sampling correlation. It is common-cause error, where shared weights, training data, post-training and retrieval reproduce the same blind spot across operators who have no way of noticing they share it.

I am not claiming three model-assisted reviews reduce to one. I am claiming we currently lack the provenance to know how much independent weight they deserve.

The fix is cheap. Every cryptanalysis note that circulates before peer review should end with two sections: who found what, and what was checked by whom, with what, and how hard. Ragavan's paper already does most of it, and ships a Lean 4 formalization that states which claims it does not cover. A kernel shares no weights with anything.

IACR has barred models from bylines since May 2025. That rule governs formal submission. It does not reach the circulating notes where Simon is actually being adjudicated.

(This post was edited by AI, but the points are mine. If anyone else wrote the same thing around the same time, blame it on ChatGPT)

https://postquantum.com/post-quantum/independence-problem-ai-cryptanalysis/

#infosec #cryptography #cryptanalysis #PQC #postquantum #formalmethods

Today, @Tutanota published a new blog post titled "Proton Mail vs Gmail: Which Is Best in 2026?". We generally don't pay attention to these biased marketing posts which end up always the same way ("neither, because we are the best"), but given the number of inaccuracies we found in it, we decided to take the time to comment it.

https://tuta.com/blog/protonmail-vs-gmail

First of all, the post doesn't differentiate security from privacy. Even if the two notions are intertwined, it's still two different concepts.

End-to-end encryption (E2EE) brings mainly privacy, that Gmail lacks heavily because it goes against Google's business model, but saying that having E2EE always brings you security is taking a shortcut. For example, most people are more exposed to email phishing than state actors' eavesdropping, and both Gmail and @protonprivacy are better at phishing detection than Tuta. We know it due to a simple fact: we recently launched a phishing simulation service (not launched publicly yet, still exploring with a few clients for now) 🙃

> Like Tuta Mail, Proton Mail has become a popular email provider for individuals and organizations who prioritize privacy and security.

This sentence tends to be understood as if Tuta preceded Proton in terms of market shares and technical standards. Also, from our experience, people tend to know Proton and not Tuta.

> [...] introducing an AI email writer defies the purpose of a private, secure email service such as Proton Mail

Even though we are against the current AI trend given its social and environmental impacts to keep it short, this sentence is also inaccurate. Scribe, Proton's writing assistant, can run locally on your own device:

https://proton.me/support/proton-scribe-writing-assistant#local-or-server.

Besides, it's an opt-in feature, it is not enabled by default.

> Users [of Proton] on the free email plan are limited to sending 150 emails daily.

Well, at least Proton gives a straight answer regarding the daily limit on a free account. From Tuta's FAQ (https://tuta.com/support/howto#email-limits):

> If you receive the following message in your Tuta account "It looks like you exceeded the number of allowed emails. Please try again later.", the anti-spam protection method has stopped your account temporarily from sending new emails. Please wait a day or two to send new emails again.

It seems there is no way to know if you are about to reach the limit before not being able to send emails for up to 2 days...

> With the free Proton Mail account, users get 1 GB of storage space.

We don't get it. It's listed in "Proton Mail downsides" whereas you also get 1 GB of storage with a free Tuta account... And with Proton, you can easily unlock 5 GB of storage with a free account...

> [...] Tuta Mail, has decided not to build a bridge for third-party desktop clients but has instead focused on developing its own native email desktop clients for Windows, Apple and Linux - and these work like a charm and are completely free.

This is part of the "Limited integrations" bullet point which is also part of the "Proton Mail downsides". That doesn't make any sense. Tuta is saying that Proton has limited integrations with third-party email clients and services (which is true), whereas Tuta has none... And regarding their "and these work like a charm" claim, sorry, but being a Tuta client since our creation in 2021, we have encountered numerous serious bugs. Like having sent emails ending up in both "Draft" and "Sent" folders with no way to know if the emails have actually been sent, the impossibility to change the language of the spell checker, getting a empty calendar because of a slow internet connection in a train whereas it is supposed to be offline-first, lost all our contact notes...

> Proton is a good choice if you’re looking for an end-to-end encrypted email provider, but it is not worth it if you compare it to Tuta Mail, the most secure quantum-proof email provider.

And there comes the inevitable conclusion that we all saw coming: "we are the best". It is the part that annoys us the most, because we are security practitioners, and we don't like false claims.

First, after 5 years of professional activity, and 10+ years with a personal account for our CEO, the amount of E2EE'd emails we have sent and received must represent roughly 1% of our exchanges (we use emails mostly for external communications). This is because Tuta made the choice to use a home-brewed implementation that only works between Tuta users. You like it or not, but the only standard for email encryption remains OpenPGP, which is annoying to use with the Tuta client. When we report security vulnerabilities to third-parties for example, we need to write and encrypt our emails in a separate text editor, encrypt them (we use @QubesOS Split GPG implementation to keep our private keys in a separate, offline, environment), and paste the result in the Tuta client...

Also, Tuta keeps talking about being an "quantum-proof email provider", but guess what? Thanks to RFC 9980, OpenPGP is quantum-proof too, meaning anyone using OpenPGP can benefit from it, including Proton:

https://proton.me/blog/introducing-post-quantum-encryption

Besides, it is a nice thing to have a strong encryption on the paper, but the implementation needs to be regularly checked for bugs and vulnerabilities. As far as we know, Tuta has never published any audit report, unlike Proton (which also has a bug bounty program: https://proton.me/security/bug-bounty).

When you do E2EE, you also need to make sure you are talking to the intended recipient, which means you need a way to verify their cryptographic public key. It turns out it took Tuta 7 years to implement it after the issue was raised to them: https://github.com/tutao/tutanota/issues/768. It means that Tuta could read all the E2EE'd exchanges on their platform without anyone noticing. Additionally, their current implementation saves the verified fingerprints locally and per-device. And given that bugs in the Tuta client regularly require to erase all local data and log back in, key verification remains mostly a gadget.

If you wonder how Proton does it: https://proton.me/support/address-verification, and https://proton.me/support/key-transparency.

To conclude, are we saying that Tuta is a bad choice? No, we will still recommend actors like Tuta which are not part of surveillance capitalism. Are we recommending Proton over Tuta? Not necessarily, it depends on multiple factors and your threat model. But we urge Tuta to improve their communication by sticking to the facts, and stop acting as if they were doing everything better than others. Because they are not.

#Tuta #Proton #Security #Privacy #Email #E2EE #PostQuantum #FOSS #EU

Today, @Tutanota published a new blog post titled "Proton Mail vs Gmail: Which Is Best in 2026?". We generally don't pay attention to these biased marketing posts which end up always the same way ("neither, because we are the best"), but given the number of inaccuracies we found in it, we decided to take the time to comment it.

https://tuta.com/blog/protonmail-vs-gmail

First of all, the post doesn't differentiate security from privacy. Even if the two notions are intertwined, it's still two different concepts.

End-to-end encryption (E2EE) brings mainly privacy, that Gmail lacks heavily because it goes against Google's business model, but saying that having E2EE always brings you security is taking a shortcut. For example, most people are more exposed to email phishing than state actors' eavesdropping, and both Gmail and @protonprivacy are better at phishing detection than Tuta. We know it due to a simple fact: we recently launched a phishing simulation service (not launched publicly yet, still exploring with a few clients for now) 🙃

> Like Tuta Mail, Proton Mail has become a popular email provider for individuals and organizations who prioritize privacy and security.

This sentence tends to be understood as if Tuta preceded Proton in terms of market shares and technical standards. Also, from our experience, people tend to know Proton and not Tuta.

> [...] introducing an AI email writer defies the purpose of a private, secure email service such as Proton Mail

Even though we are against the current AI trend given its social and environmental impacts to keep it short, this sentence is also inaccurate. Scribe, Proton's writing assistant, can run locally on your own device:

https://proton.me/support/proton-scribe-writing-assistant#local-or-server.

Besides, it's an opt-in feature, it is not enabled by default.

> Users [of Proton] on the free email plan are limited to sending 150 emails daily.

Well, at least Proton gives a straight answer regarding the daily limit on a free account. From Tuta's FAQ (https://tuta.com/support/howto#email-limits):

> If you receive the following message in your Tuta account "It looks like you exceeded the number of allowed emails. Please try again later.", the anti-spam protection method has stopped your account temporarily from sending new emails. Please wait a day or two to send new emails again.

It seems there is no way to know if you are about to reach the limit before not being able to send emails for up to 2 days...

> With the free Proton Mail account, users get 1 GB of storage space.

We don't get it. It's listed in "Proton Mail downsides" whereas you also get 1 GB of storage with a free Tuta account... And with Proton, you can easily unlock 5 GB of storage with a free account...

> [...] Tuta Mail, has decided not to build a bridge for third-party desktop clients but has instead focused on developing its own native email desktop clients for Windows, Apple and Linux - and these work like a charm and are completely free.

This is part of the "Limited integrations" bullet point which is also part of the "Proton Mail downsides". That doesn't make any sense. Tuta is saying that Proton has limited integrations with third-party email clients and services (which is true), whereas Tuta has none... And regarding their "and these work like a charm" claim, sorry, but being a Tuta client since our creation in 2021, we have encountered numerous serious bugs. Like having sent emails ending up in both "Draft" and "Sent" folders with no way to know if the emails have actually been sent, the impossibility to change the language of the spell checker, getting a empty calendar because of a slow internet connection in a train whereas it is supposed to be offline-first, lost all our contact notes...

> Proton is a good choice if you’re looking for an end-to-end encrypted email provider, but it is not worth it if you compare it to Tuta Mail, the most secure quantum-proof email provider.

And there comes the inevitable conclusion that we all saw coming: "we are the best". It is the part that annoys us the most, because we are security practitioners, and we don't like false claims.

First, after 5 years of professional activity, and 10+ years with a personal account for our CEO, the amount of E2EE'd emails we have sent and received must represent roughly 1% of our exchanges (we use emails mostly for external communications). This is because Tuta made the choice to use a home-brewed implementation that only works between Tuta users. You like it or not, but the only standard for email encryption remains OpenPGP, which is annoying to use with the Tuta client. When we report security vulnerabilities to third-parties for example, we need to write and encrypt our emails in a separate text editor, encrypt them (we use @QubesOS Split GPG implementation to keep our private keys in a separate, offline, environment), and paste the result in the Tuta client...

Also, Tuta keeps talking about being an "quantum-proof email provider", but guess what? Thanks to RFC 9980, OpenPGP is quantum-proof too, meaning anyone using OpenPGP can benefit from it, including Proton:

https://proton.me/blog/introducing-post-quantum-encryption

Besides, it is a nice thing to have a strong encryption on the paper, but the implementation needs to be regularly checked for bugs and vulnerabilities. As far as we know, Tuta has never published any audit report, unlike Proton (which also has a bug bounty program: https://proton.me/security/bug-bounty).

When you do E2EE, you also need to make sure you are talking to the intended recipient, which means you need a way to verify their cryptographic public key. It turns out it took Tuta 7 years to implement it after the issue was raised to them: https://github.com/tutao/tutanota/issues/768. It means that Tuta could read all the E2EE'd exchanges on their platform without anyone noticing. Additionally, their current implementation saves the verified fingerprints locally and per-device. And given that bugs in the Tuta client regularly require to erase all local data and log back in, key verification remains mostly a gadget.

If you wonder how Proton does it: https://proton.me/support/address-verification, and https://proton.me/support/key-transparency.

To conclude, are we saying that Tuta is a bad choice? No, we will still recommend actors like Tuta which are not part of surveillance capitalism. Are we recommending Proton over Tuta? Not necessarily, it depends on multiple factors and your threat model. But we urge Tuta to improve their communication by sticking to the facts, and stop acting as if they were doing everything better than others. Because they are not.

#Tuta #Proton #Security #Privacy #Email #E2EE #PostQuantum #FOSS #EU

Google Cloud published a dated PQC migration roadmap on 11 Aug. Nineteen dated entries against named services, which is more resolution than AWS or Microsoft has published.

Domain 1 covers store-now-decrypt-later mitigation - end of 2027. Domain 2 covers integrity and non-repudiation, Domain 3 foundations and key management, and both for 2028. Everything converges on 2029.

Google's March post said it had adjusted its threat model to prioritize authentication and digital signatures. The roadmap now puts signatures a year behind confidentiality anyway.

So I try to explain the change.

https://postquantum.com/security-pqc/google-cloud-pqc-roadmap/

#PQC #postquantum #cryptography #infosec #TLS #PKI #cloudsecurity

Google Cloud published a dated PQC migration roadmap on 11 Aug. Nineteen dated entries against named services, which is more resolution than AWS or Microsoft has published.

Domain 1 covers store-now-decrypt-later mitigation - end of 2027. Domain 2 covers integrity and non-repudiation, Domain 3 foundations and key management, and both for 2028. Everything converges on 2029.

Google's March post said it had adjusted its threat model to prioritize authentication and digital signatures. The roadmap now puts signatures a year behind confidentiality anyway.

So I try to explain the change.

https://postquantum.com/security-pqc/google-cloud-pqc-roadmap/

#PQC #postquantum #cryptography #infosec #TLS #PKI #cloudsecurity

Sí señor!

Desde #JuncoTIC somos patrocinadores de la #UbuConLA2026 que se realizará en Chile el próximo 29 y 30 de setiembre!

Estaremos sorteando accesos gratuitos a nuestros cursos, así que los que vayan a ir estén atentos a los sorteos!

Por mi parte, daré una charla sobre Criptografía Post-cuántica en #Ubuntu

Acá seguimos, apoyando eventos de #softwarelibre y #opensource, y las comunidades abiertas, que compartiendo se aprende más :-)

#UbuConLA #pqc #postquantum #cybersecurity #infosec

Sí señor!

Desde #JuncoTIC somos patrocinadores de la #UbuConLA2026 que se realizará en Chile el próximo 29 y 30 de setiembre!

Estaremos sorteando accesos gratuitos a nuestros cursos, así que los que vayan a ir estén atentos a los sorteos!

Por mi parte, daré una charla sobre Criptografía Post-cuántica en #Ubuntu

Acá seguimos, apoyando eventos de #softwarelibre y #opensource, y las comunidades abiertas, que compartiendo se aprende más :-)

#UbuConLA #pqc #postquantum #cybersecurity #infosec

Daniel Simon, creator of the algorithm that catalyzed Shor's, claims a polynomial-time quantum algorithm for the Dihedral Coset Problem (ePrint 2026/1591). If correct, the asymptotic security assumptions behind ML-KEM and ML-DSA would need reassessment.

Related interesting part: Wen and Zheng at Télécom Paris (ePrint 2026/155, accepted to CRYPTO 2026 and therefore peer-reviewed) prove that Module-LWE is quantum-polynomially equivalent to a structured dihedral variant, over the power-of-two cyclotomic rings with constant module rank that ML-KEM actually uses in production. They also reduce that structured variant to plain EDCP. The reduction chain between Simon's claim and the algorithms in your TLS stack has fewer unproven joints than it did a week ago, and half of that chain is now peer-reviewed.

Simon's paper is preliminary, several proofs are sketches, and the final SVP/LWE corollary rests on personal communications rather than published derivations. No concrete attack on any NIST parameter set is presented or costed. I am not a theoretical cryptographer and I am not declaring this proven. I am waiting for people like Micciancio, Peikert, Regev, Ducas to review it.

But this is the third event this summer hitting PQC from a different angle.

Bernstein demonstrated ML-DSA signing-key recovery in under one second by exploiting implementation flaws. The algorithm itself is fine; what organizations actually deploy is not. The attack surface is the gap between a correct specification and a correct implementation, and that gap exists in every deployment.

Anthropic's AI model autonomously recovered signing keys from HAWK-256 challenge instances. HAWK is a NIST Round 3 signature candidate, not a deployed standard, so nothing in production was touched. But the result showed that AI systems are now producing original cryptanalysis, not just assisting human researchers. Every deprecated or candidate algorithm still running in your estate became easier to attack the moment that capability crossed the line.

And now Simon's claim against the mathematical foundations themselves, with a peer-reviewed bridge connecting it to ML-KEM's specific hardness assumption.

Three different attack classes: implementation bugs found by a human, a PQC candidate broken autonomously by AI, and a theoretical quantum algorithm targeting foundational lattice assumptions.

If the lesson were just "lattice math is fragile," one event would suffice.

The lesson is that your cryptographic attack surface is wider than any single threat model covers, and the only architecture that absorbs all three is one built to replace algorithms without rebuilding infrastructure. I.e. crypto-agility.

SLH-DSA, LMS/XMSS, HQC, and everything hash-based or code-based is untouched by all of this.

Full analysis of the Simon paper, including where the proof is most vulnerable and what it means for migration planning:

https://postquantum.com/security-pqc/simon-quantum-algorithm-lattice-pqc/

#infosec #cybersecurity #PQC #postquantum #cryptography #quantum #MLKEM #latticecrypto #cryptoagility

Daniel Simon, creator of the algorithm that catalyzed Shor's, claims a polynomial-time quantum algorithm for the Dihedral Coset Problem (ePrint 2026/1591). If correct, the asymptotic security assumptions behind ML-KEM and ML-DSA would need reassessment.

Related interesting part: Wen and Zheng at Télécom Paris (ePrint 2026/155, accepted to CRYPTO 2026 and therefore peer-reviewed) prove that Module-LWE is quantum-polynomially equivalent to a structured dihedral variant, over the power-of-two cyclotomic rings with constant module rank that ML-KEM actually uses in production. They also reduce that structured variant to plain EDCP. The reduction chain between Simon's claim and the algorithms in your TLS stack has fewer unproven joints than it did a week ago, and half of that chain is now peer-reviewed.

Simon's paper is preliminary, several proofs are sketches, and the final SVP/LWE corollary rests on personal communications rather than published derivations. No concrete attack on any NIST parameter set is presented or costed. I am not a theoretical cryptographer and I am not declaring this proven. I am waiting for people like Micciancio, Peikert, Regev, Ducas to review it.

But this is the third event this summer hitting PQC from a different angle.

Bernstein demonstrated ML-DSA signing-key recovery in under one second by exploiting implementation flaws. The algorithm itself is fine; what organizations actually deploy is not. The attack surface is the gap between a correct specification and a correct implementation, and that gap exists in every deployment.

Anthropic's AI model autonomously recovered signing keys from HAWK-256 challenge instances. HAWK is a NIST Round 3 signature candidate, not a deployed standard, so nothing in production was touched. But the result showed that AI systems are now producing original cryptanalysis, not just assisting human researchers. Every deprecated or candidate algorithm still running in your estate became easier to attack the moment that capability crossed the line.

And now Simon's claim against the mathematical foundations themselves, with a peer-reviewed bridge connecting it to ML-KEM's specific hardness assumption.

Three different attack classes: implementation bugs found by a human, a PQC candidate broken autonomously by AI, and a theoretical quantum algorithm targeting foundational lattice assumptions.

If the lesson were just "lattice math is fragile," one event would suffice.

The lesson is that your cryptographic attack surface is wider than any single threat model covers, and the only architecture that absorbs all three is one built to replace algorithms without rebuilding infrastructure. I.e. crypto-agility.

SLH-DSA, LMS/XMSS, HQC, and everything hash-based or code-based is untouched by all of this.

Full analysis of the Simon paper, including where the proof is most vulnerable and what it means for migration planning:

https://postquantum.com/security-pqc/simon-quantum-algorithm-lattice-pqc/

#infosec #cybersecurity #PQC #postquantum #cryptography #quantum #MLKEM #latticecrypto #cryptoagility

Uh-oh... https://eprint.iacr.org/2026/1591

Potentially worrying. Has anyone looked into it already?

#cryptography #pqc #crypto #quantum #quantsec #postquantum #lattice

Uh-oh... https://eprint.iacr.org/2026/1591

Potentially worrying. Has anyone looked into it already?

#cryptography #pqc #crypto #quantum #quantsec #postquantum #lattice

Singapore's MAS will issue supervisory expectations for FIs' quantum-safe migration. Target: quantum resilience before end of decade. Three-phase approach: cryptographic asset inventory, prioritized migration of vulnerable systems, then technical capabilities + governance.

https://postquantum.com/security-pqc/mas-quantum-resilience-supervisory-expectations/

#infosec #cybersecurity #PQC #postquantum #quantum #cryptography #MAS #Singapore

Singapore's MAS will issue supervisory expectations for FIs' quantum-safe migration. Target: quantum resilience before end of decade. Three-phase approach: cryptographic asset inventory, prioritized migration of vulnerable systems, then technical capabilities + governance.

https://postquantum.com/security-pqc/mas-quantum-resilience-supervisory-expectations/

#infosec #cybersecurity #PQC #postquantum #quantum #cryptography #MAS #Singapore

Our August online training schedule:
1. Remaining Anonymous — free for Subscribers and Subscribers PRO
2. Post-Quantum — free for Subscribers PRO
#cybersecurity #infosec #postquantum #quantum #anonymous

For the PKI/TLS people here: Chrome's MTC test-operator program is now receiving external applications.

TrustAsia filed Chromium Issue 538260165 ("Test MTC CA Operator: [TrustAsia]") on July 24. Geomys followed on July 31. PKI standards expert Corey Bonnell surfaced the TrustAsia filing publicly and identified it as the first such application he could find in the tracker.

The technical details: TrustAsia's filing uses unsigned CA trust-anchor certificates per RFC 9925 (the general-purpose profile for X.509 certificates without cryptographic signatures, finalized Feb 2026) and the critical id-pe-mtcCertificationAuthority extension from draft-ietf-plants-merkle-tree-certs-05. The extension carries four fields — log hash algorithm, cosigner signature algorithm, and separate min/max serial number bounds. The critical marking prevents conventional path validators from misinterpreting the certificate as an ordinary intermediate.

TrustAsia qualifies for Chrome's Phase 2 (Q1 2027) through its CT log history — Chrome-qualified since 2021, with current log2026a/b shards carrying usable status, clearing the "usable log before Feb 1, 2026" threshold.

Chrome's quantum-resistant root store (CQRS) is targeted for Q3 2027. The current Chrome-Cloudflare experiment covers ~1,000 domains with classical signatures and X.509 failsafe. Production post-quantum authentication via MTC is still a 2027 target, not current reality.

My full analysis covers the web PKI fork implications for PQC migration, the RFC 9925 mechanics, Chrome's three-phase plan, and what DigiCert, Let's Encrypt, and now TrustAsia/Geomys activity means for the MTC deployment timeline:

https://postquantum.com/security-pqc/trustasia-mtc-chrome-test-root/

#infosec #cybersecurity #cryptography #PQC #postquantum #TLS #PKI #quantum

For the PKI/TLS people here: Chrome's MTC test-operator program is now receiving external applications.

TrustAsia filed Chromium Issue 538260165 ("Test MTC CA Operator: [TrustAsia]") on July 24. Geomys followed on July 31. PKI standards expert Corey Bonnell surfaced the TrustAsia filing publicly and identified it as the first such application he could find in the tracker.

The technical details: TrustAsia's filing uses unsigned CA trust-anchor certificates per RFC 9925 (the general-purpose profile for X.509 certificates without cryptographic signatures, finalized Feb 2026) and the critical id-pe-mtcCertificationAuthority extension from draft-ietf-plants-merkle-tree-certs-05. The extension carries four fields — log hash algorithm, cosigner signature algorithm, and separate min/max serial number bounds. The critical marking prevents conventional path validators from misinterpreting the certificate as an ordinary intermediate.

TrustAsia qualifies for Chrome's Phase 2 (Q1 2027) through its CT log history — Chrome-qualified since 2021, with current log2026a/b shards carrying usable status, clearing the "usable log before Feb 1, 2026" threshold.

Chrome's quantum-resistant root store (CQRS) is targeted for Q3 2027. The current Chrome-Cloudflare experiment covers ~1,000 domains with classical signatures and X.509 failsafe. Production post-quantum authentication via MTC is still a 2027 target, not current reality.

My full analysis covers the web PKI fork implications for PQC migration, the RFC 9925 mechanics, Chrome's three-phase plan, and what DigiCert, Let's Encrypt, and now TrustAsia/Geomys activity means for the MTC deployment timeline:

https://postquantum.com/security-pqc/trustasia-mtc-chrome-test-root/

#infosec #cybersecurity #cryptography #PQC #postquantum #TLS #PKI #quantum

Fact-checked the quantum sections of WEF's Top 10 Emerging Technologies 2026.

Three errors: NIST PQC took 8 years, not 2. IBM/Moderna was mRNA structure prediction, not protein folding. "Hybrid classical-quantum cryptography" is wrong terminology.

Also missing: TNFL, key-establishment/signature distinction, all NIST algorithm names.

https://postquantum.com/industry-news/wef-top-10-emerging-technologies-2026-pqc-quantum/

#infosec #PQC #postquantum #cryptography #NIST #cybersecurity

Fact-checked the quantum sections of WEF's Top 10 Emerging Technologies 2026.

Three errors: NIST PQC took 8 years, not 2. IBM/Moderna was mRNA structure prediction, not protein folding. "Hybrid classical-quantum cryptography" is wrong terminology.

Also missing: TNFL, key-establishment/signature distinction, all NIST algorithm names.

https://postquantum.com/industry-news/wef-top-10-emerging-technologies-2026-pqc-quantum/

#infosec #PQC #postquantum #cryptography #NIST #cybersecurity

IBM declared a "quantum advantage era." Three preprints make different claims, but don't confirm the declaration.

UChicago: explicit advantage claim, device-dependent fidelity certificate. Qedma: no formal advantage proof; late-time results use a heuristic. Algorithmiq: no exhaustive classical separation; accuracy bound missing.

IBM packaged three evidence levels as one.

https://postquantum.com/industry-news/ibm-three-quantum-advantage-papers/

#infosec #cybersecurity #quantum #PQC #postquantum #cryptography #IBM

IBM declared a "quantum advantage era." Three preprints make different claims, but don't confirm the declaration.

UChicago: explicit advantage claim, device-dependent fidelity certificate. Qedma: no formal advantage proof; late-time results use a heuristic. Algorithmiq: no exhaustive classical separation; accuracy bound missing.

IBM packaged three evidence levels as one.

https://postquantum.com/industry-news/ibm-three-quantum-advantage-papers/

#infosec #cybersecurity #quantum #PQC #postquantum #cryptography #IBM

A Harvard-Quantinuum-Stony Brook-UChicago collaboration published what the paper describes as the first experimental demonstration of a universal topological gate set built from braiding and fusing non-Abelian anyons, in Nature (vol. 655, pp. 591-597, July 15).

The experiment: 54 physical qubits encoding 18 six-level qudits (each qudit is a qutrit-qubit pair, three physical qubits per site) on the H2-1 trapped-ion processor. The team prepared the ground state of the quantum double of S3 (the smallest non-Abelian group), encoded logical qutrits in the fusion space of spatially separated anyons, and demonstrated three primitives: a pull-through entangling gate via coherent braiding, and logical X- and Z-basis measurements via fusion and topological-charge readout. Braiding alone is provably not universal for these simple anyons; treating fusion as a computational primitive completes the gate set, an idea from Mochon's 2004 paper. The current demonstrations use linear-depth circuits, but the paper notes all three primitives can be scalably implemented with constant-depth adaptive circuits.

Universality was illustrated by topologically preparing a magic state, the non-Clifford resource that most fault-tolerant architectures plan to build through distillation factories. The cyclic-fusion evidence from trapping a single non-Abelian anyon on the torus provides a separate diagnostic of the S3 encoding's computational power.

The caveats are in the paper's own language: stabilizing the topological phase requires active error correction, "which is beyond the scope of the present work," though a finite decoding threshold for quantum doubles with solvable groups has recently been proven. No distance-scaling result shows that a larger lattice improves logical performance. Ground-state preparation discards about 24% of shots under heralding; the most selective calibration protocol (bureau of standards) accepted 11.5% against an ideal 12.5%, with about 6% after all heralding; the magic-state protocol's acceptance was 26.52%. The pull-through gate compiled to 845 native two-qubit gates at depth 307, about 5.9s per shot.

For the CRQC picture: the magic-state result maps onto the magic-state capability in my framework at proof-of-principle level. It shows the anyonic primitives can create a non-Clifford resource but nothing yet about fault-tolerant production, injection, or logical fidelity at scale. The result widens the credible architecture set without shortening the calendar, and it raises the bar for Microsoft's materials-first Majorana approach, which pursues native topological protection in semiconductor-superconductor devices via parity measurements and measurement-based braiding.

The deeper trade this paper forces: fusion-space computing may swap the magic-state-factory overhead for a more complex preparation, measurement, and decoding stack, and this paper makes that comparison an engineering question rather than a theoretical one. Twenty-two years from Mochon's recipe to hardware. Protection is next.

Full analysis: https://postquantum.com/industry-news/universal-topological-gates-anyons/

#quantumcomputing #physics #faulttolerance #infosec #PQC #postquantum #topological

A Harvard-Quantinuum-Stony Brook-UChicago collaboration published what the paper describes as the first experimental demonstration of a universal topological gate set built from braiding and fusing non-Abelian anyons, in Nature (vol. 655, pp. 591-597, July 15).

The experiment: 54 physical qubits encoding 18 six-level qudits (each qudit is a qutrit-qubit pair, three physical qubits per site) on the H2-1 trapped-ion processor. The team prepared the ground state of the quantum double of S3 (the smallest non-Abelian group), encoded logical qutrits in the fusion space of spatially separated anyons, and demonstrated three primitives: a pull-through entangling gate via coherent braiding, and logical X- and Z-basis measurements via fusion and topological-charge readout. Braiding alone is provably not universal for these simple anyons; treating fusion as a computational primitive completes the gate set, an idea from Mochon's 2004 paper. The current demonstrations use linear-depth circuits, but the paper notes all three primitives can be scalably implemented with constant-depth adaptive circuits.

Universality was illustrated by topologically preparing a magic state, the non-Clifford resource that most fault-tolerant architectures plan to build through distillation factories. The cyclic-fusion evidence from trapping a single non-Abelian anyon on the torus provides a separate diagnostic of the S3 encoding's computational power.

The caveats are in the paper's own language: stabilizing the topological phase requires active error correction, "which is beyond the scope of the present work," though a finite decoding threshold for quantum doubles with solvable groups has recently been proven. No distance-scaling result shows that a larger lattice improves logical performance. Ground-state preparation discards about 24% of shots under heralding; the most selective calibration protocol (bureau of standards) accepted 11.5% against an ideal 12.5%, with about 6% after all heralding; the magic-state protocol's acceptance was 26.52%. The pull-through gate compiled to 845 native two-qubit gates at depth 307, about 5.9s per shot.

For the CRQC picture: the magic-state result maps onto the magic-state capability in my framework at proof-of-principle level. It shows the anyonic primitives can create a non-Clifford resource but nothing yet about fault-tolerant production, injection, or logical fidelity at scale. The result widens the credible architecture set without shortening the calendar, and it raises the bar for Microsoft's materials-first Majorana approach, which pursues native topological protection in semiconductor-superconductor devices via parity measurements and measurement-based braiding.

The deeper trade this paper forces: fusion-space computing may swap the magic-state-factory overhead for a more complex preparation, measurement, and decoding stack, and this paper makes that comparison an engineering question rather than a theoretical one. Twenty-two years from Mochon's recipe to hardware. Protection is next.

Full analysis: https://postquantum.com/industry-news/universal-topological-gates-anyons/

#quantumcomputing #physics #faulttolerance #infosec #PQC #postquantum #topological

DigiCert Quantum Readiness Outlook 2026: 87% pursuing PQC, 7% deployed quantum-safe certs at scale. <2 points of progress in a year.

Barriers: legacy complexity 26%, performance 19%, budget 19%, exec buy-in 8%, where to start 3%.

Report ignores TNFL entirely. No key-establishment vs. signature distinction. EO 14412 splits these for a reason.

https://postquantum.com/security-pqc/digicert-quantum-readiness-outlook-2026/

#infosec #cybersecurity #PQC #postquantum #quantum #cryptography

DigiCert Quantum Readiness Outlook 2026: 87% pursuing PQC, 7% deployed quantum-safe certs at scale. <2 points of progress in a year.

Barriers: legacy complexity 26%, performance 19%, budget 19%, exec buy-in 8%, where to start 3%.

Report ignores TNFL entirely. No key-establishment vs. signature distinction. EO 14412 splits these for a reason.

https://postquantum.com/security-pqc/digicert-quantum-readiness-outlook-2026/

#infosec #cybersecurity #PQC #postquantum #quantum #cryptography

HKMA just published the most granular regulator-led PQC readiness assessment I've seen from any financial authority: a 56-page whitepaper with sector-wide survey data, a four-dimensional readiness index (12 sub-indices), barrier rankings, and five completed pilot descriptions.

The headline number: Hong Kong's banking sector scores 2.3/10 on post-quantum cryptography readiness. Pilots score 1.8/10 — the weakest dimension. 71% of respondents have never conducted or planned any PoC or live testing of PQC algorithms.

The barrier data is more interesting than the score. 87% ranked third-party dependencies as a top-three obstacle. 85% said their vendors lack clear PQC roadmaps. 79% cited technical complexity of cryptographic asset discovery across legacy IT environments. Banks can't migrate what they don't control, and the vendor ecosystem hasn't given them enough to plan against.

FINMA published similar findings from Switzerland two weeks earlier: 72% of 60 surveyed institutions hadn't planned or implemented quantum-safe measures, only 8% had a roadmap. Two jurisdictions, same picture.

What the HKMA report misses: no treatment of signature forgery (Trust Now, Forge Later) as a distinct threat track alongside HNDL. For banking, this matters — a CRQC that can break ECC forges transaction authorizations on the day the capability arrives. The report also never names ML-KEM, ML-DSA, or SLH-DSA in its body (they appear only in the abbreviations appendix), and barely addresses China's divergent PQC standards program despite Hong Kong straddling both cryptographic ecosystems.

Carmen Chu (HKMA Banking Supervision) noted that banks with existing transition plans estimate 5.6 years on average to complete migration. The HKMA targets full readiness by 2030. The contradiction speaks for itself.

Full analysis: https://postquantum.com/security-pqc/hkma-banks-quantum-readiness-2-3/

#infosec #cybersecurity #PQC #postquantum #quantum #cryptography #banking #HKMA

HKMA just published the most granular regulator-led PQC readiness assessment I've seen from any financial authority: a 56-page whitepaper with sector-wide survey data, a four-dimensional readiness index (12 sub-indices), barrier rankings, and five completed pilot descriptions.

The headline number: Hong Kong's banking sector scores 2.3/10 on post-quantum cryptography readiness. Pilots score 1.8/10 — the weakest dimension. 71% of respondents have never conducted or planned any PoC or live testing of PQC algorithms.

The barrier data is more interesting than the score. 87% ranked third-party dependencies as a top-three obstacle. 85% said their vendors lack clear PQC roadmaps. 79% cited technical complexity of cryptographic asset discovery across legacy IT environments. Banks can't migrate what they don't control, and the vendor ecosystem hasn't given them enough to plan against.

FINMA published similar findings from Switzerland two weeks earlier: 72% of 60 surveyed institutions hadn't planned or implemented quantum-safe measures, only 8% had a roadmap. Two jurisdictions, same picture.

What the HKMA report misses: no treatment of signature forgery (Trust Now, Forge Later) as a distinct threat track alongside HNDL. For banking, this matters — a CRQC that can break ECC forges transaction authorizations on the day the capability arrives. The report also never names ML-KEM, ML-DSA, or SLH-DSA in its body (they appear only in the abbreviations appendix), and barely addresses China's divergent PQC standards program despite Hong Kong straddling both cryptographic ecosystems.

Carmen Chu (HKMA Banking Supervision) noted that banks with existing transition plans estimate 5.6 years on average to complete migration. The HKMA targets full readiness by 2030. The contradiction speaks for itself.

Full analysis: https://postquantum.com/security-pqc/hkma-banks-quantum-readiness-2-3/

#infosec #cybersecurity #PQC #postquantum #quantum #cryptography #banking #HKMA

Best quantum computing meta-analysis of the year: Jurczak's PFYT framework explains why quantum engineering horizons keep resetting. Backed by Riverlane QEC data and OpenAlex bibliometrics.

Where it breaks: conflating unsettled architecture with undefined targets. For CRQC and simulation workloads, the acceptance test is concrete.

https://postquantum.com/quantum-computing/perpetual-five-year-quantum-computers-pfyt/

#quantum #PQC #infosec #cryptography #postquantum

Best quantum computing meta-analysis of the year: Jurczak's PFYT framework explains why quantum engineering horizons keep resetting. Backed by Riverlane QEC data and OpenAlex bibliometrics.

Where it breaks: conflating unsettled architecture with undefined targets. For CRQC and simulation workloads, the acceptance test is concrete.

https://postquantum.com/quantum-computing/perpetual-five-year-quantum-computers-pfyt/

#quantum #PQC #infosec #cryptography #postquantum

I updated https://arewequantumyet.taffer.ca to include a link to IBM's new Quantum Advantage Tracker page.

Helpful 🤞 if you want to know whether to panic about classical private-key encryption being broken!

#quantum #QuantumComputing #PQ #PostQuantum

I updated https://arewequantumyet.taffer.ca to include a link to IBM's new Quantum Advantage Tracker page.

Helpful 🤞 if you want to know whether to panic about classical private-key encryption being broken!

#quantum #QuantumComputing #PQ #PostQuantum

Every technique used in the various July AI hacking incidents has a known defense. Weak passwords. Unauthenticated endpoints. SQL injection. Unmonitored east-west traffic. Two of three organizations Anthropic's models compromised didn't even detect it.

This is not an AI problem. It is a cybersecurity basics problem exposed at machine speed.

Vendors are already starting to market "AI-resilient" infrastructure and "Mythos-resistant" cryptography. Do not buy the label. The correct response to faster attacks is faster defense, not a different kind of defense. Shorter patching windows. Better credential rotation. Tighter segmentation. Automated rollout.

The one actually new investment: crypto-agility. In the same week OpenAI and Anthropic disclosed their hacking incidents, Anthropic's AI killed a PQC candidate that had survived years of NIST evaluation. 60 hours. $100K. HAWK was withdrawn the next day.

AI is now also attacking mathematical layer of your defenses. And the upcoming quantum threat is defeating the mathematical layer. The shared defense is the ability to swap cryptographic algorithms without rebuilding your stack.

Do good cybersecurity. Do it better. Do it faster. Build crypto-agility into the architecture.

https://postquantum.com/ai-security/ai-hacking-theater-crypto-agility/

#cybersecurity #CISO #AIhacking #cryptoagility #PQC #postquantum #infosec #AI #quantumsecurity

Every technique used in the various July AI hacking incidents has a known defense. Weak passwords. Unauthenticated endpoints. SQL injection. Unmonitored east-west traffic. Two of three organizations Anthropic's models compromised didn't even detect it.

This is not an AI problem. It is a cybersecurity basics problem exposed at machine speed.

Vendors are already starting to market "AI-resilient" infrastructure and "Mythos-resistant" cryptography. Do not buy the label. The correct response to faster attacks is faster defense, not a different kind of defense. Shorter patching windows. Better credential rotation. Tighter segmentation. Automated rollout.

The one actually new investment: crypto-agility. In the same week OpenAI and Anthropic disclosed their hacking incidents, Anthropic's AI killed a PQC candidate that had survived years of NIST evaluation. 60 hours. $100K. HAWK was withdrawn the next day.

AI is now also attacking mathematical layer of your defenses. And the upcoming quantum threat is defeating the mathematical layer. The shared defense is the ability to swap cryptographic algorithms without rebuilding your stack.

Do good cybersecurity. Do it better. Do it faster. Build crypto-agility into the architecture.

https://postquantum.com/ai-security/ai-hacking-theater-crypto-agility/

#cybersecurity #CISO #AIhacking #cryptoagility #PQC #postquantum #infosec #AI #quantumsecurity

The quantum industry has a credibility problem, and announcements like this one from EY make it worse. EY says it installed a quantum computer in Toronto for "optimization, fraud detection, data protection and large-scale risk management." No vendor named. No qubit count. No specifications. I reached out to EY's media contact and CTO - no response.

One journalist got them to confirm it's photonic.

Here's the problem: no photonic quantum computer on Earth can do optimization, fraud detection, or risk management. Not Xanadu's. Not ORCA's. Not anyone's. The photonic modality has the largest gap to useful computation of any quantum platform I track in my CRQC Scorecard.

Buying a quantum computer before they're useful? Actually smart. I wrote many posts defending exactly that logic. Procurement cycles are long. Talent is scarce. Institutional learning takes time.

But describing a research-grade photonic prototype as a machine for "processing highly sensitive workloads" in fraud detection and risk management? That's the kind of claim that makes tech execs roll their eyes at the entire quantum industry.

Joe Depa told Accounting Today the real focus is readiness and PQC. That's honest and a praiseworthy initiative. If that's what EY said, I'd congratulate them. The press release says something else. The gap between the two is the problem.

My full analysis, including two plausible vendors, what they can actually build, and what to watch for on August 5: https://postquantum.com/industry-news/ey-quantum-computer-toronto/

#QuantumComputing #PostQuantum #PQC #PhotonicQuantum #QuantumSecurity #CyberSecurity #BigFour #EY #CISO

The quantum industry has a credibility problem, and announcements like this one from EY make it worse. EY says it installed a quantum computer in Toronto for "optimization, fraud detection, data protection and large-scale risk management." No vendor named. No qubit count. No specifications. I reached out to EY's media contact and CTO - no response.

One journalist got them to confirm it's photonic.

Here's the problem: no photonic quantum computer on Earth can do optimization, fraud detection, or risk management. Not Xanadu's. Not ORCA's. Not anyone's. The photonic modality has the largest gap to useful computation of any quantum platform I track in my CRQC Scorecard.

Buying a quantum computer before they're useful? Actually smart. I wrote many posts defending exactly that logic. Procurement cycles are long. Talent is scarce. Institutional learning takes time.

But describing a research-grade photonic prototype as a machine for "processing highly sensitive workloads" in fraud detection and risk management? That's the kind of claim that makes tech execs roll their eyes at the entire quantum industry.

Joe Depa told Accounting Today the real focus is readiness and PQC. That's honest and a praiseworthy initiative. If that's what EY said, I'd congratulate them. The press release says something else. The gap between the two is the problem.

My full analysis, including two plausible vendors, what they can actually build, and what to watch for on August 5: https://postquantum.com/industry-news/ey-quantum-computer-toronto/

#QuantumComputing #PostQuantum #PQC #PhotonicQuantum #QuantumSecurity #CyberSecurity #BigFour #EY #CISO

Zig's standard library ships one of NIST's two finalised post-quantum signature standards. This is the other one.

slh-dsa-zig v0.1.1 — pure Zig SLH-DSA (FIPS 205), the hash-based scheme whose security rests on SHA-2 and SHAKE rather than lattice assumptions. All 12 parameter sets, KAT-validated against NIST ACVP, constant-time verified under Valgrind in CI.

Experimental and unaudited. Harsh review welcome.

https://nandan.me/writing/the-post-quantum-gap-in-zig/

#Zig #Cryptography #PostQuantum

Privacy is evolving.

Zerion is an open-source, Tor-native messenger focused on modern cryptography and privacy-first communication.

🌐 https://zerion.chat
💻 https://github.com/zerionproject/Zerion

#OpenSource #Privacy #PostQuantum #Tor #Encryption #FOSS #Android

Privacy is evolving.

Zerion is an open-source, Tor-native messenger focused on modern cryptography and privacy-first communication.

🌐 https://zerion.chat
💻 https://github.com/zerionproject/Zerion

#OpenSource #Privacy #PostQuantum #Tor #Encryption #FOSS #Android

Cloudflare: Erhöhte Sicherheit gegen künftige Quanten-Angriffe https://www.computerbase.de/news/internet/cloudflare-erhoehte-sicherheit-gegen-kuenftige-quanten-angriffe.98633/ #Cloudflare #PostQuantum #QuantumSecurity #PostQuantumCryptography

Cloudflare: Erhöhte Sicherheit gegen künftige Quanten-Angriffe https://www.computerbase.de/news/internet/cloudflare-erhoehte-sicherheit-gegen-kuenftige-quanten-angriffe.98633/ #Cloudflare #PostQuantum #QuantumSecurity #PostQuantumCryptography

Decentralized browser-based P2P E2EE messaging.

The key detail that sets this apart from other messaging apps is the browser-based client-side cryptography philosophy.

No need to install anything. Your ID is crypto-random and so the app doesnt need to rely on any central registration system like phone numbers. Your ID is unguessable and to connect to someone, you have to explicitly share it.

WebRTC has other nuances like being to route through a shared network for secure/faster transfer.

I hope this project has reached a level i can share the following details. I've made a genuine effort towards documentation and transparancy. I dont think it'll ever be enough and so im still concerned it isnt ready to share. While im using AI throughout. This is not a vibecoded project. There is attention throughout for unit tests and formal-verification. With your feedback, id like to make improvements for clarity throughout.

This version of the app demonstrates a fairly unique approach using a browser-based, local-only and webrtc approach. I know it's impossible for any system to be the "world's most secure", but that isnt a reason to not try. By rigorously implementing an exhaustive list of security features and practices, the aim is to get as close as possible.

* [Enkrypted.Chat](https://enkrypted.chat/)

This is intended to demonstrate client-side managed secure cryptography.

* [Introducing Enkrypted Chat](https://positive-intentions.com/blog/introducing-enkrypted-chat)
* [Whitepaper (work-in-progress)](https://positive-intentions.com/docs/technical/whitepaper/complete-whitepaper)
* [Protocol Spec (work-in-progress)](https://positive-intentions.com/docs/technical/whitepaper/complete-protocol-spec)
* [Roadmap](https://positive-intentions.com/docs/technical/p2p-messaging-technical-breakdown/)

I know ive tried to compress a lot of my journey into one post. The project above is going to be tricky to understand. Feel free to reach out for clarity on any of the details.

IMPORTANT: While this is aiming to provide a secure experience, It is [not audited or reviewed](https://www.reddit.com/r/CyberSecurityAdvice/comments/1su8lir/security_audit_feedback_from_radically_open/). **Shared for testing, feedback and demo purposes only.** Please use responsibly.

#Privacy #OnlinePrivacy #DataPrivacy #Infosec #CyberSecurity #OpSec #DigitalRights #AntiSurveillance #DataOwnership #E2EE #P2P #PeerToPeer #WebRTC #LocalFirst #LocalOnly #NoCloud #NoRegistration #PWA #SignalProtocol #PostQuantum #Cryptography #SecureMessaging #PrivateChat #EncryptedChat #Decentralized #OpenSource #SelfHosted #BetaTesting #FeedbackWelcome #TechDemo #ProofOfConcept #BuildInPublic #IndieDev #DevCommunity

Decentralized browser-based P2P E2EE messaging.

The key detail that sets this apart from other messaging apps is the browser-based client-side cryptography philosophy.

No need to install anything. Your ID is crypto-random and so the app doesnt need to rely on any central registration system like phone numbers. Your ID is unguessable and to connect to someone, you have to explicitly share it.

WebRTC has other nuances like being to route through a shared network for secure/faster transfer.

I hope this project has reached a level i can share the following details. I've made a genuine effort towards documentation and transparancy. I dont think it'll ever be enough and so im still concerned it isnt ready to share. While im using AI throughout. This is not a vibecoded project. There is attention throughout for unit tests and formal-verification. With your feedback, id like to make improvements for clarity throughout.

This version of the app demonstrates a fairly unique approach using a browser-based, local-only and webrtc approach. I know it's impossible for any system to be the "world's most secure", but that isnt a reason to not try. By rigorously implementing an exhaustive list of security features and practices, the aim is to get as close as possible.

* [Enkrypted.Chat](https://enkrypted.chat/)

This is intended to demonstrate client-side managed secure cryptography.

* [Introducing Enkrypted Chat](https://positive-intentions.com/blog/introducing-enkrypted-chat)
* [Whitepaper (work-in-progress)](https://positive-intentions.com/docs/technical/whitepaper/complete-whitepaper)
* [Protocol Spec (work-in-progress)](https://positive-intentions.com/docs/technical/whitepaper/complete-protocol-spec)
* [Roadmap](https://positive-intentions.com/docs/technical/p2p-messaging-technical-breakdown/)

I know ive tried to compress a lot of my journey into one post. The project above is going to be tricky to understand. Feel free to reach out for clarity on any of the details.

IMPORTANT: While this is aiming to provide a secure experience, It is [not audited or reviewed](https://www.reddit.com/r/CyberSecurityAdvice/comments/1su8lir/security_audit_feedback_from_radically_open/). **Shared for testing, feedback and demo purposes only.** Please use responsibly.

#Privacy #OnlinePrivacy #DataPrivacy #Infosec #CyberSecurity #OpSec #DigitalRights #AntiSurveillance #DataOwnership #E2EE #P2P #PeerToPeer #WebRTC #LocalFirst #LocalOnly #NoCloud #NoRegistration #PWA #SignalProtocol #PostQuantum #Cryptography #SecureMessaging #PrivateChat #EncryptedChat #Decentralized #OpenSource #SelfHosted #BetaTesting #FeedbackWelcome #TechDemo #ProofOfConcept #BuildInPublic #IndieDev #DevCommunity

I just published my analysis of the Anthropic HAWK/AES cryptanalysis papers. Read both against primary sources, and the coverage is getting it wrong in both directions.

"AI broke post-quantum encryption." No. HAWK is a NIST candidate, not a standard. HAWK-256 is a challenge parameter set, not a proposed security level.

"Just implementation bugs." Also no. The HAWK attack exploits a Galois symmetry (τ: ζ↦−ζ) in the power-of-two cyclotomic ring. The AES Mobius Bridge exploits the S-box's GF(2^8) inversion structure as defined in FIPS 197. These are properties of the algorithm specifications. Any correct implementation inherits them.

On the numbers: Anthropic's blog says HAWK-256 cost moved from 2^64 to 2^38. That pairing does not appear in the paper. Table 1 gives per-SVP-call costs of 2^62 and 2^38 (Core-SVP) or 2^74 and 2^52 (gate model). Every outlet running "2^64 to 2^38" is copying the blog, not the paper.

For AES, the "200-800x faster" framing describes the time term only. The attack still needs 2^105 chosen plaintexts, so the balanced complexity max(D,T,M) is unchanged at fixed data. The rebalanced variant reaches 2^96.3 vs DFJ13's 2^99. Call it a 2.7-bit improvement on 7 of 10 rounds. Real work, but production AES is untouched.

The paper that got the least attention matters most: CryptanalysisBench reports a full 128-bit key recovery on unmodified SpoC AEAD using two oracle queries, independently found by two Claude models. Also a KINDI KEM CCA-proof error leading to a working key-recovery attack. Neither scheme was deployed, but these are full-strength design breaks, not reduced-round exercises.

I try to introduce a three-tier framework for classifying cryptographic failures (implementation bug / algorithm design weakness / full-parameter break) and places each result. It also covers the independent GPT-5.6 HAWK attack, Saarinen's HOVER McEliece results, and what I got wrong in my 2025 "Why AI Cannot Break Modern Encryption" article.

https://postquantum.com/security-pqc/ai-cryptanalysis-hawk-aes/

#infosec #cryptography #PQC #postquantum #HAWK #AES #cryptanalysis #cybersecurity

What is the UK AI Growth Lab and who should use it?

The UK AI Growth Lab, announced 8 June 2026, brings regulators including the ICO, the SRA and the Legal Services Board together to guide organisations deploying AI, starting with lawtech and conveyancing. It offers practical steer, not a safe harbour; deployments still need to be evidenced.

https://mickai.co.uk/articles/what-is-the-uk-ai-growth-lab-and-who-should-use-it

#SovereignAI #AI #DataSovereignty #PostQuantum #AIgovernance

Matthew McPherrin from Let's Encrypt doing a talk next Wednesday at TASK on post quantum readiness, TLS, and many things. Streaming link on site. https://www.task.to/schedule/july2026-business-resilience-post-quantum-tls #TASK #Toronto #Crypto #PostQuantum #PQ #InfoSec
Edit: There are five Wednesdays this month