Why RSA's Public Exponent Is 65537, and the PKCS#8 vs PKCS#1 Format Trap

Guide · Last verified Aug 28, 2026

Anyone who's generated an RSA key has probably noticed the number "65537" appear somewhere. Let's walk through why it's almost always that exact value, and why two similar-looking PEM headers — "BEGIN RSA PRIVATE KEY" and "BEGIN PRIVATE KEY" — end up causing parsing errors in different programs.

1. Why 65537 — not 3, and not just any large prime

An RSA public key is the pair (n, e), where e is the public exponent. In theory e can be any value that satisfies certain conditions, but in practice it's almost always 65537 (2¹⁶+1, the Fermat prime F4). In binary that's 10000000000000001 — only two bits set to 1. Modular exponentiation works by repeating "square, then multiply" for each bit, so fewer 1-bits mean fewer multiplications, which makes encryption and signature verification faster. On the other end, an exponent that's too small — like e=3 — becomes vulnerable to low-exponent attacks that can, under certain conditions, recover the plaintext without the private key. 65537 sits between these two extremes as the de facto industry standard that satisfies both computational efficiency and resistance to attack.

2. PKCS#1 vs PKCS#8: same RSA key, different header

When exporting a private key as PEM, there are actually two distinct formats in use. PKCS#1 is an RSA-specific format using the "-----BEGIN RSA PRIVATE KEY-----" header — the key structure only implicitly carries the fact that it's RSA. PKCS#8 is a general-purpose format using the "-----BEGIN PRIVATE KEY-----" header, and it explicitly embeds an algorithm identifier (AlgorithmIdentifier) that states whether the key is RSA, EC, or something else. In other words, PKCS#8 bakes "this key is RSA" into the file itself, while PKCS#1 leaves that information for the reader (context) to already know.

3. Why parsing fails so often: every program expects a different format

Some libraries are written to read only PKCS#8; some legacy tools recognize only PKCS#1. Even OpenSSL itself outputs a different default format depending on the version — the genrsa command traditionally outputs PKCS#1, while genpkey outputs PKCS#8. So the common complaint "I definitely generated an RSA key, but this other program won't read it" is, more often than not, not a flaw in the algorithm at all — it's a mismatch between the two formats' headers and structure. The RSA Key Generator uses Web Crypto API's exportKey('pkcs8', ...), always exporting the private key as PKCS#8 and the public key as X.509 SPKI (SubjectPublicKeyInfo), which keeps it compatible with virtually all modern tools.

4. Converting between the formats

If you receive a PKCS#1 key but need PKCS#8 for a given program, you can convert it with openssl pkcs8 -topk8 -nocrypt -in pkcs1.pem -out pkcs8.pem. To go the other way, from PKCS#8 back to PKCS#1, use openssl rsa -in pkcs8.pem -out pkcs1.pem. If you're not sure which format you have, just open the file and check the first line — "RSA PRIVATE KEY" means PKCS#1; its absence means PKCS#8.

5. How this connects to adjacent tasks like CSRs and SSH

The exponent and format questions carry over directly into other RSA-related work. Generating a CSR before issuing an SSL certificate relies internally on the same kind of RSA key pair, and a private key produced by the CSR Generator is just as subject to the PKCS#1/PKCS#8 format issue. SSH keys, on the other hand, use an entirely different OpenSSH-specific format, so it's safer to generate those separately with the SSH Key Generator.

Frequently Asked Questions