New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Correlation Between Key Length and Execution Time #1080
Comments
|
This issue seems to have assigned CVE-2021-43398. |
|
I think I'm missing something... if you have the private key already, you know its length. You can only call How can a correlation between key length and a function's runtime be dangerous if you have to possess the private key already in order to call the function in the first place? In the absence of further explanation, the CVE entry is misleading and should be withdrawn. |
|
Thanks @CindyZhouYH. Please provide your test program and some data points. I would like to see how you generate your private keys for a particular curve, and how you can correlate a private key length to execution time beyond the field size. Naively, it seems to me there's nothing interesting about determining how many bytes are in the private key. I think that leaks one bit of information (the MSB position), and I don't think that's an interesting problem. Also, Crypto++ multiplies words and not bytes. A word is 8 bytes. The chances of all 8 bytes being 0 so the 65th-bit is leaked is 1 / 2^64. That's a really small probability, and I don't think the MSB position is leaked in practice.
Something sounds a bit off here. A 256-bit curve will have a private key that is 64 bytes long; and a 521-bit curve will have a private key that is 132 bytes long. How do you have a private key that is hundreds of bytes long? They key should be rejected during loading or during validation. |
|
Would you provide your test program and data points, please. Thanks in advance. |
|
Isn't it obvious that the longer the key is - the longer the operations with it would take? Did somebody really assigned a CVE on this?! Update: yes, as you increase the size of the curve generator to whatever, you're likely to reach a point when your computer takes forever (literally!) to operate on that key. It's called math... |
|
Hi Everyone, We are going to close this a "not a bug". We believe it is expected behavior. We don't believe the CVE is valid. @CindyZhouYH, if you can provide a test program and test data we would be happy to revisit it. |
|
@noloader are you (as upstream) going to ask MITRE (via cveform.mitre.org ideally) for a REJECT of the CVE? (or at least being marked disputed if there is not consensus with the reporter that the CVE is not valid) |
|
I'm not sure who acquired the CVE, so I am not sure who to contact about withdrawaling it. Mitre's CVE webform is unusable. I tired to use it to obtain a CVE but I could not submit the form. I lost my taste for the webform. Mitre should re-enable the email address. |
|
@noloader the assigning CNA was MITRE, but the metadata does not disclose who requested it. I just have asked MITRE if they can reject the CVE. |
|
Thanks @carnil. |
|
Sorry for the delayed reply. @geoffbeier @noloader @carnil @mouse07410 On the contrary, the execution time of OpenSSL on the same function remains unchanged, which is a correct performance because it will not disclose the information of the privacy data participating in the algorithm. You can check it through the following testfile. |
|
My RSA private key is 4096 bits. My ECDSA key is 380 bits. Feel free to use this info to crack them. |
|
@mouse07410 You are really the wisest man I ever met. I even didn't know what math was until you explained it! Thank you for your great help. It is a great @noloader @CindyZhouYH |
|
@CindyZhouYH Could you please give some theoretical background on why OpenSSL does implement this in constant time as @tomlemmon asked? Is there any known attack that chains the keysize with something else? Because I agree with @mouse07410 that in itself this should not be an issue? I am not from the cryptography community, so a detailed explanation would be very helpful, thanks! |
https://github.com/weidai11/cryptopp/releases/tag/CRYPTOPP_8_7_0 Note there is a bogus CVE ID assigned to versions <= 8.6.0 (CVE-2021-43398). See upstream discussion for more information weidai11/cryptopp#1080

I'm using Crypto++ built by the latest version of source code in this repository on Ubuntu 18.04.
The function is as follows:
It seems that the execution time of
privateKey.MakePublicKey(publicKey)is positively correlated with the length of the private key instead of a constant value. I did a simple experiment and heres the result. But I haven't studied the reason yet.I suppose this may leak the length information of the input private key and facilitate malicious attacks on key decryption.
Besides, the execution time becomes abnormally long when the private key reaches hundreds of bytes long, which causes a little inconvenience to me.
Hope you can check this case.
The text was updated successfully, but these errors were encountered: