Cryptography Fundamentals Questions

Direct answer

Forward secrecy (also called perfect forward secrecy, PFS) means that if an attacker later
steals a server's long-term private key, they still cannot decrypt traffic they recorded in
the past, because each past session used its own key that was never derivable from the
long-term key in the first place. It does not protect a session whose own key is compromised
while that session is still relevant, or protect anything on either endpoint after
decryption.

Structured elaboration

• What it protects against: mass retroactive decryption. An attacker who passively
  records encrypted traffic for years, then later compromises the server's long-term private
  key (via a breach, subpoena, or key-extraction bug), gains nothing from the recording: the
  long-term key was only ever used to authenticate, not to directly encrypt.
• What it does not protect against: compromise of a specific session's own ephemeral key
  or the derived session key while that session's data is still sensitive; endpoint
  compromise (malware reading plaintext directly on a client or server); and metadata (who
  talked to whom, when, how much data), which forward secrecy says nothing about.
• How ECDHE achieves it in TLS: ECDHE (elliptic-curve Diffie-Hellman, ephemeral) means
  both sides generate a brand-new elliptic-curve key pair for every handshake, exchange the
  public halves, and derive a shared secret via elliptic-curve Diffie-Hellman. The server's
  long-term certificate key is only used to sign that ephemeral exchange (proving "this really
  is me"), never to encrypt anything directly. Once the handshake finishes, both sides discard
  the ephemeral private keys, so nothing recoverable from the long-term key remains.
• What an operator must actually configure: enable and prefer cipher suites containing
  ECDHE (or classic DHE), for example TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, and disable
  static-RSA key-exchange suites (TLS_RSA_WITH_...), where the session key is directly
  RSA-encrypted with the server's long-term public key and is therefore fully recoverable if
  that private key ever leaks. TLS 1.3 (RFC 8446) removes static-RSA key exchange entirely and
  makes ephemeral exchange mandatory, so upgrading to it is itself a forward-secrecy fix.
  Session resumption is the other place this quietly breaks: if session tickets are encrypted
  under a long-lived ticket key, compromising that ticket key can undo forward secrecy for
  every resumed session, so ticket keys need their own rotation schedule.

Worked example

An attacker passively records two years of encrypted traffic between a client and
bank.example.com. In year three, the bank suffers a breach and its long-term certificate
private key leaks. If the bank's TLS configuration used ECDHE, the attacker's two-year
recording is still worthless: every one of those sessions used its own ephemeral key pair,
generated and discarded at handshake time, and the leaked long-term key was never used to
encrypt anything, only to sign the ephemeral exchange. If the bank had instead used a static-RSA
key-exchange suite, the same leaked key directly decrypts every recorded session key from the
last two years, because in that mode the session key was RSA-encrypted straight to the server's
long-term public key and never expires on its own.

Trade-offs & pitfalls

• A server can support ECDHE in principle and still fail to get forward secrecy in practice
  if a legacy static-RSA suite is still enabled and a client or load balancer negotiates down
  to it.
• Forward secrecy adds a small amount of per-handshake computation (a fresh key exchange
  every time versus a single static RSA operation), which is why it was historically seen as
  a cost/security trade rather than a default; TLS 1.3 settled that trade by removing the
  alternative.

Direct answer

Elliptic curve cryptography (ECC) does the same job as RSA, public-key encryption and
signatures, using the algebraic structure of points on an elliptic curve instead of large
integer factorization. It reaches the same security level as RSA with much smaller keys,
because the best known attack against the underlying elliptic-curve discrete-log problem has
no sub-exponential shortcut, unlike RSA's factorization problem.

Structured elaboration

• Key sizes: a 256-bit elliptic-curve key (P-256) provides roughly the same security as a
  3072-bit RSA key; a 384-bit curve (P-384) roughly matches a 7680-bit RSA key. The gap widens
  as the target security level rises.
• Computational cost: ECC signing and key-generation operations are cheap compared to RSA
  at an equivalent security level, since RSA's cost grows faster than ECC's as key size
  increases. RSA public-key verification is actually cheap in absolute terms (a small public
  exponent keeps that operation fast), but RSA's private-key operations and key generation get
  noticeably expensive at 3072+ bits.
• Bandwidth: ECC keys and signatures are dramatically smaller, a P-256 ECDSA signature is
  roughly 64 bytes versus roughly 256 to 384 bytes for an RSA-2048/3072 signature. This matters
  directly for TLS handshake size, mobile bandwidth, and embedded/IoT devices with tight memory
  budgets.
• Use cases: ECDSA for digital signatures, ECDH (and its ephemeral form, ECDHE) for key
  exchange, both filling the same roles RSA and classic Diffie-Hellman fill, just cheaper.
• Named curves: P-256 (also called secp256r1, a NIST-standardized curve) is the most
  widely deployed; Curve25519 (used for X25519 key exchange) and Ed25519 (its signature
  counterpart) are increasingly preferred, in part because their parameters were generated
  through a fully documented, deterministic process, addressing concerns some practitioners
  raised about the opacity of how certain NIST curve constants were originally chosen.

Worked example

A mobile app performs 1,000,000 TLS handshakes a day against its API. Each handshake carries
one server certificate signature. An RSA-3072 signature runs roughly 384 bytes; a P-256 ECDSA
signature runs roughly 64 bytes, a saving of 320 bytes per handshake. Across a day:
1,000,000 x 320 bytes = 320,000,000 bytes, that is, about 320 MB of signature bytes saved
daily just from the certificate switch, before counting any of the other handshake fields ECC
also shrinks. For a bandwidth-constrained mobile client population, that is a real, measurable
reason to prefer ECDSA over RSA beyond the abstract "smaller keys" framing.

Trade-offs & pitfalls

• ECC implementations are more delicate than RSA's: incorrect point validation, timing
  side-channels during scalar multiplication, and "invalid curve" attacks are all
  ECC-specific implementation pitfalls that a naive from-scratch implementation is likely to
  get wrong. "Don't roll your own crypto" applies even more strongly to ECC than to RSA.
• Choice of curve matters beyond raw key size: Curve25519/Ed25519 are designed to make
  several classes of implementation mistakes (like weak point validation) structurally harder
  to make than the older NIST curves do.

Direct answer

Public Key Infrastructure (PKI) is the system of certificates, certificate authorities, and
trust chains that lets a stranger's public key be trusted without meeting them first. A
certificate authority (CA) signs a certificate binding a public key to an identity; anyone who
already trusts that CA can then trust the certificate, and by extension the key inside it.

Structured elaboration

flowchart TD
    Root["Root CA (trust anchor, pre-installed in OS/browser)"]
    Inter["Intermediate CA (signed by Root)"]
    Leaf["Server certificate (signed by Intermediate)"]
    Root -->|signs| Inter
    Inter -->|signs| Leaf
    Leaf -->|presented during TLS handshake| Client["Client validates the whole chain"]

• Certificate: a data structure containing a public key, an identity (like a domain
  name), a validity window, and a signature from whoever issued it.
• Certificate authority (CA): a party trusted to verify identity claims before signing a
  certificate. Trust in a CA is not proven cryptographically from scratch each time, it comes
  from the CA's root certificate being pre-installed as a trust anchor in operating systems
  and browsers.
• Certificate chains: in practice, a root CA rarely signs end-entity (leaf) certificates
  directly; it signs intermediate CAs, which sign the leaf certificates servers actually
  present. Validating a certificate means walking this chain, checking each signature, until
  reaching a root the client already trusts.
• Use in TLS: during the handshake, the server presents its certificate (and usually the
  intermediate chain); the client verifies the signature chain up to a trusted root, checks
  the domain name matches, and checks the validity window, before it will trust the public
  key for the key exchange.

Worked example

A browser connecting to example.com receives a leaf certificate for example.com signed by
"Intermediate CA X," which is itself signed by "Root CA R." The browser already has Root CA
R's certificate baked into its trust store. It verifies Intermediate CA X's signature using
Root CA R's public key, then verifies the leaf certificate's signature using Intermediate CA
X's public key. Only after both signatures check out, the domain name matches, and the
current date falls inside the leaf certificate's validity window does the browser proceed to
trust that public key for the handshake.

Trade-offs & pitfalls

• Certificate expiration: every certificate in the chain has a validity window; if the
  leaf certificate's window ends and it is not renewed, clients will refuse the connection (or
  warn loudly) even though nothing about the underlying keys has actually changed. This is a
  frequent, entirely avoidable cause of production outages, which is why certificate expiry is
  tracked as an operational alert, not just a one-time setup step.
• Self-signed certificates skip the CA entirely (the certificate signs itself), which is fine
  for internal testing but provides no independent identity verification for anyone who
  hasn't been told in advance to trust that specific certificate.

Direct answer

A cryptographic hash function must be preimage resistant (given an output, you cannot find
an input that produces it), second-preimage resistant (given one input, you cannot find a
different input with the same output), and collision resistant (you cannot find any two
distinct inputs that share an output at all). Common algorithms today are SHA-256 and SHA-3;
MD5 and SHA-1 are broken for collision resistance and should not be used where that property
matters.

Structured elaboration

• Preimage resistance: given H(m) = h, it should be computationally infeasible to find
  any m that produces h. This is what makes a hash "one-way."
• Second-preimage resistance: given a specific m1, it should be infeasible to find a
  different m2 with H(m1) = H(m2).
• Collision resistance: it should be infeasible to find any pair m1 != m2 with
  H(m1) = H(m2), without fixing either input in advance. This is the property MD5 and SHA-1
  have both practically broken (real collision attacks have been demonstrated for both).
• Where a hash is the right tool: integrity checks (comparing a downloaded file's hash
  against a published one to detect corruption or tampering), content-addressing (Git commit
  hashes, package registries keying content by its digest so identical content always maps to
  the same address), and as the digest step inside a digital signature: signing algorithms
  sign a fixed-size hash of a message rather than the message itself, since asymmetric
  operations are expensive on large inputs.
• Where it is not the right tool: storing passwords with a bare, unsalted hash. Hash
  functions are deliberately fast, which is exactly wrong for password storage: an attacker
  with a stolen hash dump can try billions of guesses per second on commodity GPUs. Password
  storage needs a slow, memory-hard key derivation function (Argon2id, scrypt, bcrypt), not a
  general-purpose hash used directly.

Worked example

To see why collision resistance is the strongest property, compare a real hash to a toy,
clearly-broken one: H(x) = x mod 97. Take m1 = 5 and m2 = 102. 102 mod 97 = 5, so
H(5) = H(102) = 5: a collision found by inspection, with no search at all. That is exactly
what "not collision resistant" looks like. A real hash like SHA-256 produces a 256-bit output,
so the best known way to find any colliding pair is a generic birthday-bound search of roughly
2^128 attempts (the square root of 2^256 possible outputs), which is computationally out
of reach with current or foreseeable hardware. The mod-97 toy fails instantly because its
output space is only 97 values; a cryptographic hash needs both a large output space and no
structural shortcut into it.

Trade-offs & pitfalls

• Collision resistance and preimage resistance are different properties; a function can lose
  one without immediately losing the other, which is why "MD5 has collisions" does not
  automatically mean "MD5 leaks passwords," but it does mean you should not trust MD5 for
  anything where an attacker choosing two colliding inputs would matter (like forging a signed
  document).
• "Hashing" and "encryption" are often confused: hashing is one-way and not meant to be
  reversed at all, encryption is two-way and meant to be reversed with the right key. A hash
  cannot be "decrypted" back to the original input, by design.

Direct answer

Roughly: AES-128 or AES-256 for symmetric keys, at least RSA-2048 with RSA-3072 preferred for
longer-lived data, and a 256-bit elliptic curve (like P-256) for ECDSA/ECDH. These are not
interchangeable "bit strengths": because the underlying hard problems differ, RSA needs a
much larger key than AES or ECC to reach the same practical security level.

Structured elaboration

Key length matters because it determines how expensive the best known attack is. For a
symmetric cipher, the best general attack is brute force over the key space, so security
scales directly and exponentially with key bits. RSA's security instead rests on integer
factorization, which has sub-exponential algorithms (the General Number Field Sieve), so RSA
needs a much larger key to match a given symmetric strength. Elliptic-curve cryptography
relies on the discrete logarithm problem over an elliptic curve, which has no known
sub-exponential attack, so it reaches strong security with much smaller keys than RSA.

Roughly matched security levels (NIST SP 800-57 style guidance):

Operational considerations that influence the choice:

• Performance: RSA key generation and private-key operations get noticeably slower as key
  size grows; ECC stays comparatively cheap even at higher security levels, which is why TLS
  handshakes favor ECDHE over large-RSA key exchange today.
• Lifespan: a key protecting data that must stay confidential for decades (a root CA, an
  archival encryption key) should sit at a higher security margin than a short-lived TLS
  session key, since attacker capability only improves over time.
• Algorithm migration headroom: teams often deliberately keep some headroom above the
  current minimum recommendation, so that a future algorithm migration (moving to a larger
  key size, or off an algorithm entirely) can happen on a planned schedule rather than as an
  emergency re-key after a break is announced.

Worked example

A document-signing service needs signatures that remain verifiable for 20-year regulatory
retention. A TLS session key, by contrast, only needs to resist attack for the minutes the
connection is open. Both could technically use "128-bit class" security today, but the
signing service deliberately picks RSA-3072 over RSA-2048 (or a 384-bit curve over a 256-bit
one) precisely because of the lifespan consideration: a 20-year window gives attacker capability
two decades to improve, so the team spends a bit more compute per signature now to buy margin
that a short-lived session key does not need.

Trade-offs & pitfalls

• RSA-2048 is still widely deployed and considered acceptable for most near-term use, but
  guidance is trending toward RSA-3072 for anything expected to remain secure for many years;
  treat any bare "RSA-2048 is fine forever" claim with suspicion.
• Bumping AES from 128 to 256 bits has essentially no practical performance cost on modern
  hardware (AES-NI accelerates both equally), so the "just use AES-256 to be safe" instinct is
  cheap here in a way it is not for RSA.