Описание
In Bouncy Castle for Java before 1.86, HQC leaked secret-derived data through two side channels: its GF(2^8) arithmetic used lookup tables indexed by field elements, making the cache line touched a function of the operand, and its fixed-weight support sampler left its duplicate scan as soon as a collision was found and stored accepted positions at a secret index. Both run on secret inputs during encapsulation and decapsulation, and the sampler re-expands the secret key from its seed on every decapsulation, so an attacker able to observe cache behaviour or decapsulation timing can recover information about the HQC private key. The field arithmetic is now table-free and the sampler branch-free within a batch of candidates, with output and randomness consumption unchanged.
A flaw was found in Bouncy Castle. The Hamming Quasi-Cyclic (HQC) cryptographic algorithm leaks secret data through memory cache access patterns and execution timing variations during key encapsulation and decapsulation operations. A local attacker capable of monitoring cache activity or measuring operation timing could exploit this vulnerability to recover information about the private cryptographic key.
Отчет
A side-channel vulnerability was discovered in Bouncy Castle's implementation of the Hamming Quasi-Cyclic (HQC) algorithm. The implementation performs non-constant-time Galois field arithmetic via operand-indexed lookup tables and executes branch-dependent operations during fixed-weight support sampling in key encapsulation and decapsulation routines. A local attacker sharing the physical host can observe memory cache line accesses or measure execution timing variations during cryptographic operations to extract sensitive intermediate state, ultimately reconstructing the HQC private key.
Меры по смягчению последствий
Avoid using the HQC algorithm for cryptographic key encapsulation in shared or multi-tenant environments. Configure applications to use alternative constant-time key encapsulation mechanisms until patched packages can be deployed.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| OpenShift Developer Tools and Services | jenkins | Fix deferred | ||
| OpenShift Developer Tools and Services | jenkins-2-plugins | Fix deferred | ||
| OpenShift Developer Tools and Services | ocp-tools-4/jenkins-rhel8 | Fix deferred | ||
| OpenShift Developer Tools and Services | ocp-tools-4/jenkins-rhel9 | Fix deferred | ||
| Red Hat AMQ Broker 7 | bcprov-jdk18on | Fix deferred | ||
| Red Hat Ansible Automation Platform 2 | ansible-automation-platform-27/de-minimal-rhel9 | Fix deferred | ||
| Red Hat Ansible Automation Platform 2 | ansible-automation-platform-27/de-supported-rhel9 | Fix deferred | ||
| Red Hat build of Apache Camel 4 for Quarkus 3 | bcprov-jdk18on | Fix deferred | ||
| Red Hat build of Apache Camel for Spring Boot 4 | bcprov-jdk18on | Fix deferred | ||
| Red Hat build of Apicurio Registry 3 | bcprov-lts8on | Fix deferred |
Показывать по
Дополнительная информация
Статус:
EPSS
5.1 Medium
CVSS3
Связанные уязвимости
In Bouncy Castle for Java before 1.86, HQC leaked secret-derived data through two side channels: its GF(2^8) arithmetic used lookup tables indexed by field elements, making the cache line touched a function of the operand, and its fixed-weight support sampler left its duplicate scan as soon as a collision was found and stored accepted positions at a secret index. Both run on secret inputs during encapsulation and decapsulation, and the sampler re-expands the secret key from its seed on every decapsulation, so an attacker able to observe cache behaviour or decapsulation timing can recover information about the HQC private key. The field arithmetic is now table-free and the sampler branch-free within a batch of candidates, with output and randomness consumption unchanged.
In Bouncy Castle for Java before 1.86, HQC leaked secret-derived data through two side channels: its GF(2^8) arithmetic used lookup tables indexed by field elements, making the cache line touched a function of the operand, and its fixed-weight support sampler left its duplicate scan as soon as a collision was found and stored accepted positions at a secret index. Both run on secret inputs during encapsulation and decapsulation, and the sampler re-expands the secret key from its seed on every decapsulation, so an attacker able to observe cache behaviour or decapsulation timing can recover information about the HQC private key. The field arithmetic is now table-free and the sampler branch-free within a batch of candidates, with output and randomness consumption unchanged.
In Bouncy Castle for Java before 1.86, HQC leaked secret-derived data ...
In Bouncy Castle for Java before 1.86, HQC leaked secret-derived data through two side channels: its GF(2^8) arithmetic used lookup tables indexed by field elements, making the cache line touched a function of the operand, and its fixed-weight support sampler left its duplicate scan as soon as a collision was found and stored accepted positions at a secret index. Both run on secret inputs during encapsulation and decapsulation, and the sampler re-expands the secret key from its seed on every decapsulation, so an attacker able to observe cache behaviour or decapsulation timing can recover information about the HQC private key. The field arithmetic is now table-free and the sampler branch-free within a batch of candidates, with output and randomness consumption unchanged.
EPSS
5.1 Medium
CVSS3