Crypto++ 8.3.0 and earlier contains a timing side channel in ECDSA signature generation. This allows a local or remote attacker, able to measure the duration of hundreds to thousands of signing operations, to compute the private key used. The issue occurs because scalar multiplication in ecp.cpp (prime field curves, small leakage) and algebra.cpp (binary field curves, large leakage) is not constant time and leaks the bit length of the scalar among other information.
From a private email by Ján Jančár:
 

> Message-ID: <93874bd8-653e-33e9-c429-93712c3f30ba@mail.muni.cz>
> Subject: Vulnerability disclosure
> ...
> 
> During our research into security of elliptic curve cryptography implementations on smart-cards and in software libraries [1], we have discovered timing leakage in the ECDSA signature generation in the Crypto++ library.
> 
> *Vulnerability description*
> 
> When performing ECDSA over binary field curves, Crypto++ leaks the bit-length of the nonce used in scalar multiplication. It also leaks some other currently unknown information, see the attached plots, specifically the 'msb_hist.png' plot.
> 
> This leakage can be abused if an attacker is able to measure the duration of signing of a few hundreds or thousands of known messages. The attacker can then use a lattice attack based on the Hidden Number Problem [2] to reconstruct the private key used, as demonstrated in [3] (even remotely!).
> 
> See the attached plots and heatmaps for details of the leakage on the standard sect233r1 curve. based on the level of noise present in the attacker's measurements (the lattice attack is very sensitive to noise) and willingness to trade-off computation time, the attack would require from 500 to 10k signatures.
> 
> The private key recovery itself, assuming a noise free set of just enough signatures, would then take a few minutes. The leakage is somewhat present in ECDSA over prime field curves as well, but much smaller, I do not know the cause of this.
> 
> [1]: ECTester: https://crocs-muni.github.io/ECTester/
> 
> [2]: D. Boneh, R. Venkatesan: Hardness of computing the most significant bits of secret keys in Diffie-Hellman and related schemes; https://crypto.stanford.edu/~dabo/abstracts/dhmsb.html
> 
> [3]: B. B. Brumley, N. Tuveri: Remote Timing Attacks are Still Practical; https://eprint.iacr.org/2011/232.pdf

It appears nearly all versions of Crypto++ are affected. Based on some research of antique Crypto++, I believe that means Crypto++ 3.2 and forward. Crypto++ 3.2 was released March 20, 2000.

Also posted to the mailing list at [ECDSA timing leaks](https://groups.google.com/forum/#!topic/cryptopp-users/1GGTAh4CEdA).
Elliptic Curve timing leaks
This is a GitHub Issue
repo:cryptopp
owner:weidai11
Title : Elliptic Curve timing leaks
Issue date:

--- start body ---
From a private email by Ján Jančár:
 

> Message-ID: <93874bd8-653e-33e9-c429-93712c3f30ba@mail.muni.cz>
> Subject: Vulnerability disclosure
> ...
> 
> During our research into security of elliptic curve cryptography implementations on smart-cards and in software libraries [1], we have discovered timing leakage in the ECDSA signature generation in the Crypto++ library.
> 
> *Vulnerability description*
> 
> When performing ECDSA over binary field curves, Crypto++ leaks the bit-length of the nonce used in scalar multiplication. It also leaks some other currently unknown information, see the attached plots, specifically the 'msb_hist.png' plot.
> 
> This leakage can be abused if an attacker is able to measure the duration of signing of a few hundreds or thousands of known messages. The attacker can then use a lattice attack based on the Hidden Number Problem [2] to reconstruct the private key used, as demonstrated in [3] (even remotely!).
> 
> See the attached plots and heatmaps for details of the leakage on the standard sect233r1 curve. based on the level of noise present in the attacker's measurements (the lattice attack is very sensitive to noise) and willingness to trade-off computation time, the attack would require from 500 to 10k signatures.
> 
> The private key recovery itself, assuming a noise free set of just enough signatures, would then take a few minutes. The leakage is somewhat present in ECDSA over prime field curves as well, but much smaller, I do not know the cause of this.
> 
> [1]: ECTester: https://crocs-muni.github.io/ECTester/
> 
> [2]: D. Boneh, R. Venkatesan: Hardness of computing the most significant bits of secret keys in Diffie-Hellman and related schemes; https://crypto.stanford.edu/~dabo/abstracts/dhmsb.html
> 
> [3]: B. B. Brumley, N. Tuveri: Remote Timing Attacks are Still Practical; https://eprint.iacr.org/2011/232.pdf

It appears nearly all versions of Crypto++ are affected. Based on some research of antique Crypto++, I believe that means Crypto++ 3.2 and forward. Crypto++ 3.2 was released March 20, 2000.

Also posted to the mailing list at [ECDSA timing leaks](https://groups.google.com/forum/#!topic/cryptopp-users/1GGTAh4CEdA).
--- end body ---
