EXERCISE 1 — Decoding ECDHE-ECDSA-AES256-GCM-SHA384
====================================================

Split the string on its four segments:

  ECDHE - ECDSA - AES256-GCM - SHA384
  \___/   \___/   \________/   \____/
   kex     auth     cipher       hash

(1) ECDHE  = Key exchange
    Elliptic-Curve Diffie-Hellman EPHEMERAL.
    Contributes: agrees the shared symmetric secret.
    The "E" (ephemeral) => FORWARD SECRECY.

(2) ECDSA  = Authentication
    The server's certificate uses an Elliptic-Curve (ECDSA) key to SIGN
    and prove its identity. (Contrast with ...-RSA-... where the cert key
    is RSA.)
    Contributes: AUTHENTICATION (defeats impersonation).

(3) AES256-GCM = Bulk cipher
    256-bit AES in GCM mode — a symmetric AEAD cipher encrypting the
    actual application data.
    Contributes: CONFIDENTIALITY + INTEGRITY together (AEAD).

(4) SHA384 = Hash / PRF
    SHA-384 used for key derivation and the handshake MAC/Finished.
    Contributes: integrity of the handshake + key schedule.

GUARANTEE MAPPING:
    Confidentiality -> AES256-GCM (encryption)
    Integrity       -> GCM's built-in auth tag + SHA384
    Authentication  -> ECDSA certificate signature
    Forward secrecy -> ECDHE (ephemeral)

DOES IT PROVIDE FORWARD SECRECY?  YES.
    The key exchange is ECDHE (ephemeral), so each session uses one-time
    DH values that are discarded afterward. Stealing the server's
    long-term ECDSA key later cannot decrypt past sessions.

NOTE: This is the all-elliptic-curve variant (ECDHE + ECDSA), common on
modern servers with EC certificates. Functionally equivalent security to
ECDHE-RSA-AES256-GCM-SHA384; the difference is just the certificate key
type (ECDSA vs RSA).