Описание
The ECDSA implementation of the Elliptic package generates incorrect signatures if an interim value of 'k' (as computed based on step 3.2 of RFC 6979 https://datatracker.ietf.org/doc/html/rfc6979 ) has leading zeros and is susceptible to cryptanalysis, which can lead to secret key exposure. This happens, because the byte-length of 'k' is incorrectly computed, resulting in its getting truncated during the computation. Legitimate transactions or communications will be broken as a result. Furthermore, due to the nature of the fault, attackers could–under certain conditions–derive the secret key, if they could get their hands on both a faulty signature generated by a vulnerable version of Elliptic and a correct signature for the same inputs.
This issue affects all known versions of Elliptic (at the time of writing, versions less than or equal to 6.6.1).
The ECDSA implementation of the Elliptic package generates incorrect signatures if an interim value of 'k' has leading zeros and may potentially expose a secret key. A similar miscalculation can happen whenever the size of the message digest is longer than the size of the curve. As a result invalid signatures may be generated which validate when tested. If an attacker can arbitrarily construct input they may also be able to expose the secret signing key.
Меры по смягчению последствий
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Logging Subsystem for Red Hat OpenShift | openshift-logging/elasticsearch6-rhel9 | Fix deferred | ||
| Logging Subsystem for Red Hat OpenShift | openshift-logging/elasticsearch-operator-bundle | Fix deferred | ||
| Logging Subsystem for Red Hat OpenShift | openshift-logging/elasticsearch-proxy-rhel9 | Fix deferred | ||
| Logging Subsystem for Red Hat OpenShift | openshift-logging/elasticsearch-rhel9-operator | Fix deferred | ||
| Logging Subsystem for Red Hat OpenShift | openshift-logging/kibana6-rhel8 | Fix deferred | ||
| Logging Subsystem for Red Hat OpenShift | openshift-logging/logging-curator5-rhel9 | Fix deferred | ||
| Red Hat 3scale API Management Platform 2 | 3scale-amp20/system | Fix deferred | ||
| Red Hat 3scale API Management Platform 2 | 3scale-amp21/system | Fix deferred | ||
| Red Hat 3scale API Management Platform 2 | 3scale-amp22/system | Fix deferred | ||
| Red Hat 3scale API Management Platform 2 | 3scale-amp24/system | Fix deferred |
Показывать по
Дополнительная информация
Статус:
5.6 Medium
CVSS3
Связанные уязвимости
The ECDSA implementation of the Elliptic package generates incorrect signatures if an interim value of 'k' (as computed based on step 3.2 of RFC 6979 https://datatracker.ietf.org/doc/html/rfc6979 ) has leading zeros and is susceptible to cryptanalysis, which can lead to secret key exposure. This happens, because the byte-length of 'k' is incorrectly computed, resulting in its getting truncated during the computation. Legitimate transactions or communications will be broken as a result. Furthermore, due to the nature of the fault, attackers could–under certain conditions–derive the secret key, if they could get their hands on both a faulty signature generated by a vulnerable version of Elliptic and a correct signature for the same inputs. This issue affects all known versions of Elliptic (at the time of writing, versions less than or equal to 6.6.1).
The ECDSA implementation of the Elliptic package generates incorrect signatures if an interim value of 'k' (as computed based on step 3.2 of RFC 6979 https://datatracker.ietf.org/doc/html/rfc6979 ) has leading zeros and is susceptible to cryptanalysis, which can lead to secret key exposure. This happens, because the byte-length of 'k' is incorrectly computed, resulting in its getting truncated during the computation. Legitimate transactions or communications will be broken as a result. Furthermore, due to the nature of the fault, attackers could–under certain conditions–derive the secret key, if they could get their hands on both a faulty signature generated by a vulnerable version of Elliptic and a correct signature for the same inputs. This issue affects all known versions of Elliptic (at the time of writing, versions less than or equal to 6.6.1).
The ECDSA implementation of the Elliptic package generates incorrect s ...
Elliptic Uses a Cryptographic Primitive with a Risky Implementation
5.6 Medium
CVSS3