Skip to content
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

Add checks to verify correctness of RSA/DSA/ElGamal keys #50

Closed
wants to merge 3 commits into from

Conversation

Projects
None yet
2 participants
@Legrandin
Copy link
Contributor

Legrandin commented Jun 17, 2013

When the various components are assembled into an RSA,
DSA or ElGamal key via the construct() method, we must verify
as much as possible if the result is indeed a valid key.

NOTE: this patch also rolls back introduction of the Crypto.PublicKey.KeyFormatError exception. That was done with the DSA key import functionality, but I think there is still not enough consensus of how exceptions should be introduced: the ValueError is now thrown instead of KeyFormatError.

Legrandin added some commits Jun 17, 2013

Add checks to verify correctness of RSA/DSA/ElGamal keys
When the various components are assembled into an RSA,
DSA or ElGamal key via the construct() method, we must verify
as much as possible if the result is indeed a valid key.
FIX #1193521: mpz_powm_sec crashes when modulus is odd
When importing a key, we verify that all components
that will be used as modulus for mpz_powm_sec() are odd.
Use mpz_powm_sec() only when needed.
mpz_powm_sec() is useful when exercising the private key
(signature or decryption).

When the public key is used or when the input is random
and produced locally, there is no real need for it.
@dlitz

This comment has been minimized.

Copy link

dlitz commented on lib/Crypto/PublicKey/ElGamal.py in 8acf0d7 Feb 22, 2014

Thanks for fixing the import *

@dlitz

This comment has been minimized.

Copy link

dlitz commented on lib/Crypto/PublicKey/DSA.py in 8acf0d7 Feb 22, 2014

Hm. IIRC, pow isn't constant-time, and there doesn't appear to be any blinding applied here. Could this leak the private key x via timing information?

This comment has been minimized.

Copy link
Owner Author

Legrandin replied Mar 1, 2014

Unlikely, I think. Let's say that an application can be tricked to load the private key by a remote attacker, and the attacker can measure how long it takes.
If this is the only private key in the system, the time is somewhat constant, because the attacker does not contribute to the operation with any data or parameter (as opposed to say, a decryption).
If there are several private keys in the system, the attacker could measure the difference in loading time between the various keys, but I doubt this can be exploited in practice.

@dlitz

This comment has been minimized.

Copy link

dlitz commented on lib/Crypto/PublicKey/ElGamal.py in 8acf0d7 Feb 22, 2014

Ditto. Are we leaking the private key x via a timing side-channel here?

This comment has been minimized.

Copy link
Owner Author

Legrandin replied Mar 1, 2014

Same argument as above. :-)

@Legrandin Legrandin closed this May 20, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.