Applied Cryptography and Key Management Questions

Answer (concise, role-focused)

Cryptographic differences

• RSA key exchange: server's long-term RSA private key decrypts the pre-master secret sent by client (or signs key material). Security depends on secrecy of that single private key.
• ECDHE: client and server perform an ephemeral elliptic-curve Diffie-Hellman handshake; both contribute ephemeral keys to derive session keys. Server uses long-term key only to sign the ephemeral parameters (authentication), not to derive session keys.

Impact on PFS

• RSA key exchange: no perfect forward secrecy. If the server's long-term private key is later compromised, an attacker who recorded past TLS sessions can decrypt them (recover pre-master secret).
• ECDHE: provides PFS. Compromising server long-term key allows impersonation/active attacks going forward but not decryption of past sessions because ephemeral private keys used for those sessions were not stored.

Consequences of later compromise

• RSA: full retroactive decryption of recorded sessions.
• ECDHE: recorded sessions remain confidential; attacker can only forge new sessions after compromise.

Server configuration changes I would make

• Prioritize ECDHE cipher suites (e.g., TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) and disable RSA key-exchange suites.
• Enable strong curves (e.g., secp256r1, x25519) and prefer x25519 for performance/security.
• Use a modern TLS version (>=1.2, preferably 1.3) — TLS 1.3 mandates (EC)DHE and drops RSA key exchange.
• Configure short-lived TLS private keys where practical, enforce strong key sizes, and restrict legacy/weak ciphers (RC4, 3DES, EXPORT).
• Enable forward-secrecy-capable session resumption (ticket encryption keys rotated frequently).
• Monitor and rotate cert/private keys on compromise; log and alert unusual certificate operations.

These changes ensure PFS for recorded traffic and reduce blast radius of long-term key compromise while balancing interoperability and performance.