Subject: [Contribution] Mitigating EPER Threat Vectors Across Classical and PQC Frameworks
Srini Katta
Hello PQC Forum,
I am writing to share research regarding an urgent operational gap in the cryptographic transition: Encryption-Based Extortion and Ransomware (EPER).
Our research indicates that the move to NIST PQC standards (FIPS 203/204) introduces a unique "Management Gap." While the industry focuses on algorithm robustness, automated adversarial AI is targeting the governance layer to execute "Encrypt with PQC, Enforce Ransom" attack loops that bypass traditional log-based detection.
Key Research Points:
Dual-Stack Vulnerability: Attackers are leveraging the "Legacy Tail" of RSA/ECC and the un-governed deployment of ML-KEM to execute under 72-minute encryption cycles.
The Observer’s Dilemma: Why passive monitoring fails against machine-speed extortion.
Inline Cryptographic Governance: A proposed architecture using Normalized CBOMs and protocol-level interceptors to authorize cryptographic intent in real-time.
By integrating a Normalized Cryptographic Bill of Materials (CBOM) into the migration lifecycle, organizations can maintain a unified inventory of all cryptographic actions—classical and post-quantum—to neutralize unauthorized re-encryption at the execution layer.
The link to the abstract is here https://docs.google.com/document/d/1rgRAsgx5smY4PZB16YyU7aTPwtk0_bw2/edit?usp=sharing&ouid=102433854967620066459&rtpof=true&sd=true
I look forward to discussing how these governance frameworks can be standardized to support a more resilient PQC migration.
Best regards,
Srini
Founder & CEO,
Qubit Guard
Austin, Texas
Brent Kimberley
RFC 9180, ML-KEM512, Asconpq80 ?
From: pqc-...@list.nist.gov <pqc-...@list.nist.gov>
On Behalf Of Srini Katta
Sent: May 5, 2026 4:05 PM
To: pqc-forum <pqc-...@list.nist.gov>
Subject: [pqc-forum] Subject: [Contribution] Mitigating EPER Threat Vectors Across Classical and PQC Frameworks
|
You don't often get email from sr...@qubitguardian.com. Learn why this is important |
|
⚠️CAUTION: This email is from an external source. Verify sender before opening links and attachments.⚠️ |
--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
pqc-forum+...@list.nist.gov.
To view this discussion visit
https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/10d49fad-f398-40b2-9793-aad8dcb8e88fn%40list.nist.gov.
Srini Katta
Hi Brent,
Those are exactly the right points to drill into.
When we look at RFC 9180 (HPKE), it’s clear that the crypto-agility it provides is a massive win for legitimate developers, but it’s also a powerful tool for an adversary. In an EPER scenario, an attacker can use that same HPKE framework to rapidly swap in unauthorized parameters at machine speed. Our focus is ensuring that the "interceptor" can govern those KEM/KDF choices in real-time, rather than just logging the event after the encryption is already complete.
Regarding ML-KEM-512, its efficiency is a bit of a double-edged sword. It’s perfect for a smooth PQC migration, but that same low latency is what allows a "wrap-and-ransom" loop to execute so quickly that traditional human-scale monitoring can't keep up. That "speed gap" is really the heart of the "Observer’s Dilemma" we're trying to solve.
I’m also glad you mentioned Ascon-pq-80. Constrained edge devices are often the "governance dark spots" in an enterprise. We believe that even lightweight implementations need to be represented in a Normalized CBOM so they don't become easy targets for lateral movement during a ransom attack.
Are you currently seeing any friction when trying to enforce consistent policy across these different HPKE or lightweight stacks in your own environment?
Best regards,
Srini Founder & CEO,
Qubit Guard