You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SNYK and other scanning tools alerts on package vulnerability ( Timing Attack ) found at "sign_digest" API function.
( ecdsa.SigningKey.sign_digest() )
Hi @tomato42, can you give more details on what you mean by "timing attacks are outside the scope of the project."? Does it mean that ecdsa is not affected or just that resolving that vulnerability is responsibility of the users of ecdsa? Thanks
@dlpzx I mean that Python doesn't provide the primitives that are side-channel free, so it's impossible to build a side-channel free implementation on top of them. To actually fix it, it would require implementing the whole operation in C, which is a non-goal for the library (as it won't be a pure-python any more)
IMO it doesn't make sense to be ideological about pure-python when it means every end-user that has to meet security requirements (anyone that delivers code for enterprise) will no longer use the library :/
I don't want people to use this library in production environments...
It's a teaching tool, it's a testing tool, it's absolutely not an production grade implementation.
I maintain it to have support for ECDH and ECDSA in tlsfuzzer, which I need to be first and foremost portable. Security does not even enter a picture for that tool.
If you need enterprise grade implementation you should use pyca/cryptography.
Reacted by Sefa Eyeoglu, Seth Arnold, Ryan Jarvis and Kate
Activity
maksimu commentedon Jan 24, 2024
We are also interesting is the ETA for the fix
tomato42 commentedon Jan 24, 2024
as stated in the vulnerability release GHSA-wj6h-64fc-37mp and as stated in the security policy timing attacks are outside the scope of the project.
If you need an implementation that is safe against side-channel attacks, I recommend using https://github.com/pyca/cryptography
It's a won't fix.
alopezlopez4 commentedon Feb 13, 2024
Hi @tomato42, can you give more details on what you mean by "timing attacks are outside the scope of the project."? Does it mean that
ecdsais not affected or just that resolving that vulnerability is responsibility of the users of ecdsa? Thankstomato42 commentedon Feb 13, 2024
@dlpzx I mean that Python doesn't provide the primitives that are side-channel free, so it's impossible to build a side-channel free implementation on top of them. To actually fix it, it would require implementing the whole operation in C, which is a non-goal for the library (as it won't be a pure-python any more)
eshgovil commentedon Sep 24, 2025
IMO it doesn't make sense to be ideological about pure-python when it means every end-user that has to meet security requirements (anyone that delivers code for enterprise) will no longer use the library :/
tomato42 commentedon Sep 25, 2025
I don't want people to use this library in production environments...
It's a teaching tool, it's a testing tool, it's absolutely not an production grade implementation.
I maintain it to have support for ECDH and ECDSA in tlsfuzzer, which I need to be first and foremost portable. Security does not even enter a picture for that tool.
If you need enterprise grade implementation you should use pyca/cryptography.
Tools: remove python ecdsa dependency
Tools: remove python ecdsa dependency
python3-ecdsa: ignore CVE-2024-23342
python3-ecdsa: ignore CVE-2024-23342
Replace ecdsa with cryptography (#104)
fix(lint): report shellcheck errors, check scripts in dot-dirs (#16)