Nice Cryptography
Exploiting Common Prime Factors in RSA Public Keys
Introduction
In this challenge, we were provided with two RSA public keys. The task was to retrieve the encrypted flag. The vulnerability comes from a well-known RSA misconfiguration: two different RSA public keys sharing a common prime factor.
When this happens, the security of both keys is broken because their moduli can be factored efficiently using the greatest common divisor (GCD). Once the prime factors are known, we can recover the private key and decrypt the ciphertext.
Step 1: Extracting the Modulus from the Public Keys
We started by extracting the modulus nn from each public key using OpenSSL:
openssl rsa -pubin -text -noout -in pub1.pem

This outputs the modulus (N) in hexadecimal format. Since we need to perform arithmetic operations, we converted the modulus values into decimal form using Python.
Step 2: Converting Hexadecimal to Decimal and Checking for a Common Factor
We used a small Python script to parse the hex-encoded modulus, convert it into decimal, and compute the GCD:
Running this script revealed a non-trivial GCD, which is one of the shared primes (pp) used in both keys.
Step 3: Factoring the Moduli
With p known, factoring both modulus values becomes trivial:

Step 4: Recovering the Private Key

Step 5: Decrypting the Flag
Finally, we built a private RSA key object and used it to decrypt the ciphertext.
The script used to automate these steps was:
This script successfully recovered the plaintext, which contained the flag.

Why Shared Primes Happen in Practice
RSA relies heavily on generating two large random primes pp and qq. The security assumption is that factoring the modulus n=p×qn = p \times q is computationally infeasible when both primes are unique and strong. However, in practice, shared primes have been observed in real-world systems due to several reasons:
1. Weak or Reused Random Number Generators (RNGs)
If the random number generator used to pick pp and qq is not cryptographically secure, it may output predictable or repeated values. For example:
Some embedded devices or IoT devices use weak entropy sources (e.g., system time at boot) to generate keys.
If two devices boot at similar times with the same weak RNG, they may generate identical primes.
This was observed in research studies where millions of RSA keys on the internet were scanned, and many were found sharing prime factors.
2. Faulty Key Generation Implementations
Poorly implemented cryptographic libraries or custom RSA key generators may:
Accidentally reuse one prime across different key generations.
Fail to check if p=qp = q (leading to a trivial factorization).
Not properly reseed the RNG, leading to repeated sequences.
3. Historical Incidents
Several notable incidents demonstrated this vulnerability in practice:
2012 “Mining Your Ps and Qs” Paper (Lenstra et al.): Researchers scanned millions of public keys and found that ~0.4% of RSA keys shared primes due to bad randomness.
Debian OpenSSL Bug (2006–2008): A flaw in Debian’s OpenSSL package severely reduced entropy, leading to a huge number of predictable keys.
Conclusion
The challenge demonstrated a critical RSA vulnerability: shared prime factors between public keys. By computing the GCD of two moduli, we were able to recover the prime, factor the moduli, reconstruct the private key, and decrypt the ciphertext.
This is why cryptographic libraries must ensure proper randomness in key generation. Reusing or accidentally sharing prime numbers completely breaks RSA security.
Thank you all! I hope you enjoyed the article. If you have any questions, I’m here to help.
Remember My name : everythingBlackkkMade
by ❤
Github : https://github.com/everythingBlackkk
Linkedin : www.linkedin.com/in/everythingblackkk
Last updated