Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

There are several papers from 2012 that say it's possible to factor several moduli by factoring shared primes. The link above includes python sourcecode to verify and test for this fact.

Given this knowledge, what should I do as an IT Security Professional with regard to all my server's SSL certificates, and other encryption artifacts that may or may not be vulnerable.


  • If SSL is vulnerable, is it a good idea for me to test and reissue affected certificates? Or should I simply change the ciphers that my web server uses?

  • Is prior encrypted data from RSA or DHE based sessions vulnerable?

share|improve this question
"Is prior encrypted data from RSA or DHE based sessions vulnerable?" - DHE will be fine, since breaking or leaking the long-term RSA private key still won't reveal the per-session DH private key. – Polynomial Jun 30 '13 at 18:16
The underlying problem is PRNG failure, which is pretty hard to detect and hard to work around. – CodesInChaos Jun 30 '13 at 19:02

If it is simple enough to test, then you might as well do so. I don't know of any service or other mechanism that will do this test for you, but if you do then have at it. The likelihood of an attack is probably pretty slim, but the severity is pretty extreme. It's certainly worth fixing if you detect it.

Yes, any prior sessions, if captured, can be decrypted if your private key can be derived. Unless you use Diffie-Hellman to generate your ephemeral session key (currently extremely uncommon); just search for "Perfect Forward Secrecy" for information about protecting today's sessions against tomorrow's attacks.

Note that your primes are determined when you generate your key, not your certificate. Generating a key costs nothing (but your time) and can be done as many times as you please. So if you're going to test, you might as well generate the key ahead of time (or perhaps several in one go) test, and then generate a CSR based only on a "strong" key. A computer with a good TRNG (such as recent Linuxes and BSDs) is helpful here, since a bad PRNG is typically your source of bad keys.

Also, several CAs will allow you to "re-key" a certificate, which essentially means issue a new one with the original expiration date. So if at any point your key is suspect, that may be an option.

share|improve this answer

If you've just created a new key, don't bother testing it. Instead, you're better off making sure that when you create a new key, you use good randomness. This is a situation where prevention is a lot easier than detection.

The researchers found that the problem you're referring to arises primarily with private keys that were generated on embedded devices (e.g., consumer wireless access points, DSL routers, etc.). Those devices tend to have poor PRNGs and (often) sloppy key-generation code. In contrast, if you generated your key on a server using reputable software (e.g., OpenSSL), you're probably fine.

(Exception: The Debian failure affected some people, but that was quite a while ago and should not affect keys that were generated in the past year or two.)

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.