Ensuring Sufficient Entropy in RSA Modulus Generation

Wendy MuHenry Corrigan-Gibbs

Dan Boneh

Motivation #1

• Security of RSA relies on hardness of factoring modulus

• What happens when , are generated with faulty random number generators?

Motivation #1

• A study by Heninger et al. (2012) found…

• 5.57% of TLS hosts had same private keys as another host

• 0.50% of these hosts’ private keys were easily computed through finding all-pairs GCDs

Motivation #1

Reason for these common factors?Weak entropy!

Motivation #2

• Kleptography (Young and Yung, 1996)• Attack where third party can figure out

private key• Malicious black box key generator encrypts

in last bits of )

• Third party with key can decrypt and factor

----------------------------------------------- ----------------------------------------------

----------- ------------

Goals

• An efficient way for a host to obtain randomness from a trusted source with high entropy

• A way for the host to prove that the generated modulus was generated using the given randomness

Overview

Entropy Authority Certificate Authority

TLS Host (e.g., web server)

Key generationprotocol

Key verificationprotocol

Overview

Entropy Authority Certificate Authority

TLS Host (e.g., web server)

3. EA-signed

certificate

2. EA-signed certificate

1. Modulus generation

4. CA-signedcertificate

Building blocks

• Pedersen commitments (Pedersen)

• Computationally binding• Information theoretically hiding• Additively homomorphic

Building blocks

• Zero-knowledge proofs• Prove that and are commitments to and

with (Cramer and Damgard)

Building blocks

• Public-key signature scheme (Goldwasser et al.)• Sign and verify functions• Existentially unforgeable

Protocol: Modulus Generation

Host Entropy Authority

Choose random

Find next primes

commitments to

Choose random

Check is right sizeCheck small

Compute commitments to ,

Execute proof of knowledge

signature on

Protocol: Modulus Generation

Public values:

Host Entropy Authority 1024 bits

Check is 2048 bitsCheck small

Execute proof of knowledge

Protocol: Modulus Verification

Host Certificate Authority

signed certificate

Verify EA signature

Application: SSH

Entropy Authority SSH Client

SSH Server

3. EA-signed

certificate

2. EA-signed certificate

1. Modulus generation

Security

• are 1024 bit primes• are 20 bit numbers• is 2048 bits• (modulus for commitments) is 2148

bits (100 bits more than ), since

Security

• Desired properties:• Maintain secrecy of and • Ensure resulting contains sufficient

entropy

Security

• If the host has no entropy, a global eavesdropper could always learn and • Assume that the host gets a free

communication with EA

• Assume host is not malicious

Even if the host has low entropy, the resulting modulus will be as strong as an RSA modulus generated using the traditional algorithm with high entropy.

If the host has high entropy, the EA cannot learn anything about and .

If the host does not follow the protocol, either the EA or CA will be able to detect the violation, or the resulting will still have high entropy.

Therefore, a misbehaving host cannot get a CA to sign a low-entropy key.

Performance

• On a laptop…• Traditional RSA: 0.59s• Our protocol: 3.18s

Performance

• On a Linksys router…• Traditional RSA: 59.6s• Our protocol: 111.7s

• Includes ~100ms RTT network latency

• Relatively small overhead: ~2x

Related Work

• Juels and Guajardo (2002) introduced the idea of a randomness authority, with a protocol for key generation

• Uses range proofs (proving a commitment is to an integer in a given range)• Expensive, many calculations

• Our protocol avoids range proofs faster

Future work

• Integrate protocol into certificate signing request to CA

Conclusion

• Protocol for generating an RSA modulus with sufficient randomness

• Feasible to implement on today’s hardware

• Small overhead to traditional RSA

Contact: wmu@cs.stanford.edu