Researcher Finds Side-Channel Vulnerability in Post-Quantum Key Encapsulation Mechanism (thecyberexpress.com) 12
Slashdot reader storagedude shared this report from The Cyber Express:
A security researcher discovered an exploitable timing leak in the Kyber key encapsulation mechanism (KEM) that's in the process of being adopted by NIST as a post-quantum cryptographic standard. Antoon Purnal of PQShield detailed his findings in a blog post and on social media, and noted that the problem has been fixed with the help of the Kyber team. The issue was found in the reference implementation of the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) that's in the process of being adopted as a NIST post-quantum key encapsulation standard. "A key part of implementation security is resistance against side-channel attacks, which exploit the physical side-effects of cryptographic computations to infer sensitive information," Purnal wrote.
To secure against side-channel attacks, cryptographic algorithms must be implemented in a way so that "no attacker-observable effect of their execution depends on the secrets they process," he wrote. In the ML-KEM reference implementation, "we're concerned with a particular side channel that's observable in almost all cryptographic deployment scenarios: time." The vulnerability can occur when a compiler optimizes the code, in the process silently undoing "measures taken by the skilled implementer." In Purnal's analysis, the Clang compiler was found to emit a vulnerable secret-dependent branch in the poly_frommsg function of the ML-KEM reference code needed in both key encapsulation and decapsulation, corresponding to the expand_secure implementation.
While the reference implementation was patched, "It's important to note that this does not rule out the possibility that other libraries, which are based on the reference implementation but do not use the poly_frommsg function verbatim, may be vulnerable — either now or in the future," Purnal wrote.
Purnal also published a proof-of-concept demo on GitHub. "On an Intel Core i7-13700H, it takes between 5-10 minutes to leak the entire ML-KEM 512 secret key using end-to-end decapsulation timing measurements."
To secure against side-channel attacks, cryptographic algorithms must be implemented in a way so that "no attacker-observable effect of their execution depends on the secrets they process," he wrote. In the ML-KEM reference implementation, "we're concerned with a particular side channel that's observable in almost all cryptographic deployment scenarios: time." The vulnerability can occur when a compiler optimizes the code, in the process silently undoing "measures taken by the skilled implementer." In Purnal's analysis, the Clang compiler was found to emit a vulnerable secret-dependent branch in the poly_frommsg function of the ML-KEM reference code needed in both key encapsulation and decapsulation, corresponding to the expand_secure implementation.
While the reference implementation was patched, "It's important to note that this does not rule out the possibility that other libraries, which are based on the reference implementation but do not use the poly_frommsg function verbatim, may be vulnerable — either now or in the future," Purnal wrote.
Purnal also published a proof-of-concept demo on GitHub. "On an Intel Core i7-13700H, it takes between 5-10 minutes to leak the entire ML-KEM 512 secret key using end-to-end decapsulation timing measurements."
It's why the process started a decade ago (Score:4)
It's worth noting this is basically the development process working as intended. But it's interesting reading - and a reminder (to myself at least) that there are people out there who are far more clever at this stuff than I am.
Government is annoyed (Score:1)
"A security researcher discovered"... the backdoor they left open in the "public" reference implementation.
Re: (Score:2)
No evidence? Check. Wild accusation? Check. Reference to a deep dark "government" scheme? Check.
A Conspiracy!!! Damn, you caught us. You could tell Fox about it, they never require any evidence, and they'll link it to their other zoo of conspiracies.
Re: (Score:2)
You're jumping to conclusions.
FWIW, I think they'd build the reference implementation without backdoors, and slip the backdoors into the "more efficient implementation". So I think your guess is wrong. But that doesn't mean I don't think there are agents acting as you suppose.
Another one bites the dust (Score:2)
This "post quantum" encryption is so crappy, everybody should stay far away from it. Sure, _maybe_ we will need it one day (or maybe not), but standardizing anything at thit time is obviously excessively premature.
Of course, it is possible all this "post quantum" stuff, at a time where there is not a single QC that could do anything worth doing and it is completely unclear how things will progress, might just be an effort to make people use breakable encryption. Yes, that is a conspiracy theory. But there r
Re: (Score:3)
You are ignoring the cases where you don't want someone to be able to decrypt it a decade or so from now. Messages sent now can be stored for later decryption...and there's strongly suggestive evidence that some entities are doing just that.
Re: (Score:2)
No, I am not. QCs will not be at that stage in a decade. Or two. And maybe not even ten.
The problem with quantum encryption (Score:2)
The processing at both ends of the quantum encryption pipe has to be done by ordinary electronics. It's a case of security being only as strong as the weakest link.
Interesting (Score:2)
Don't use C (Score:2)