Public Key Cryptography & PKI Architecture: RSA vs ECDSA vs Ed25519, Key Exchange & Browser WebCrypto

The Core Premise of Asymmetric Cryptography

Unlike symmetric encryption (such as AES-GCM or ChaCha20), which requires communicating parties to share a common secret key over a secure pre-existing channel, asymmetric (public key) cryptography utilizes mathematically paired keys:

• Public Key: Shared openly with anyone; used to encrypt messages intended for the recipient or verify digital signatures produced by the recipient.
• Private Key: Kept strictly confidential by the owner; used to decrypt messages or produce non-repudiable digital signatures.

1. RSA (Rivest-Shamir-Adleman)

Introduced in 1977, RSA derives its cryptographic hardness from the Integer Factorization Problem: given a large composite integer n = p * q (where p and q are massive prime numbers), finding p and q is computationally infeasible with classical computers using the General Number Field Sieve (GNFS).

While RSA has stood the test of time for decades, its key sizes must grow dramatically to maintain security margins as computational power expands:

• RSA-1024: Broken and deprecated since 2013.
• RSA-2048: Minimum acceptable size today (provides ~112 bits of security).
• RSA-4096: Recommended for long-lived root Certificate Authorities (~128 bits of security), but introduces substantial CPU and memory overhead during key generation and signing.

2. Elliptic Curve Cryptography: ECDSA & Ed25519

Elliptic Curve Cryptography (ECC) achieves equivalent security to RSA with orders of magnitude smaller keys by operating over the points of an algebraic curve defined by y² = x³ + ax + b (mod p). Cryptographic strength relies on the Elliptic Curve Discrete Logarithm Problem (ECDLP): calculating Q = k * P is trivial via point addition, but determining the scalar k given Q and P is mathematically intractable.

The two primary modern elliptic curve signature standards are:

NIST Curves (ECDSA with P-256 / secp256r1)

Widely adopted in TLS 1.3 and WebAuthn/FIDO2. A 256-bit key delivers equivalent security to RSA-3072. However, traditional ECDSA implementations require a cryptographically unique random nonce for every signature. If a faulty RNG generates the same nonce twice, an attacker can extract the private key via elementary algebra (the exact vulnerability that compromised the Sony PlayStation 3 security architecture).

Edwards-curve Digital Signature Algorithm (Ed25519)

Designed by Daniel J. Bernstein et al., Ed25519 uses a Twisted Edwards curve (Curve25519) and provides superior architectural benefits:

• Deterministic Signatures: Eliminates random nonce generation by computing the nonce from a hash of the private key and message, making signature generation immune to weak RNG attacks.
• Constant-Time Execution: Immune to cache-timing and branch-prediction side-channel attacks by design.
• High Throughput: Capable of verifying tens of thousands of signatures per second on standard consumer hardware.

Performance & Key Size Comparison

Algorithm	Security Level	Public Key Size	Signature Size	Signing Speed
RSA-2048	~112 bits	256 bytes	256 bytes	Slow (~1,200 ops/s)
RSA-4096	~128 bits	512 bytes	512 bytes	Very Slow (~180 ops/s)
ECDSA P-256	~128 bits	64 bytes	64 bytes	Fast (~15,000 ops/s)
Ed25519	~128 bits	32 bytes	64 bytes	Ultra Fast (~30,000 ops/s)

Browser WebCrypto API Example

Modern web applications can generate cryptographic keys and sign payloads directly inside the user's browser without transferring private keys to backend servers:

// Generate an ECDSA P-256 keypair in the browser
const keyPair = await window.crypto.subtle.generateKey(
  {
    name: "ECDSA",
    namedCurve: "P-256"
  },
  true,
  ["sign", "verify"]
);

// Sign arbitrary data with SHA-256
const encoder = new TextEncoder();
const data = encoder.encode("Client-side identity assertion payload");
const signature = await window.crypto.subtle.sign(
  {
    name: "ECDSA",
    hash: { name: "SHA-256" }
  },
  keyPair.privateKey,
  data
);