Exercise 2: The Paint-Mixing Analogy and Forward Secrecy — Possible Solution
====================================================================

How both parties end up with the same shared secret:

1. Both parties agree publicly on a shared starting color (this is
   public information, known to any eavesdropper too).
2. Party A secretly mixes in their own private color, producing
   Mixture A, and sends Mixture A to Party B over the public channel.
3. Party B secretly mixes in their own private color, producing
   Mixture B, and sends Mixture B to Party A over the public channel.
4. Party A takes the received Mixture B and mixes in THEIR OWN private
   color again.
5. Party B takes the received Mixture A and mixes in THEIR OWN private
   color again.
6. Both operations combine the SAME THREE ingredients in total (the
   shared starting color, A's private color, and B's private color) --
   just added in a different order for each party -- so both arrive at
   the exact same final combined color.

Why an eavesdropper can't recover it:

The eavesdropper only ever sees the PUBLIC starting color, Mixture A,
and Mixture B -- never either party's actual private color on its own,
and never the final combined result either (that's never transmitted
at all, only derived independently by each party). Working backward
from an already-mixed color to recover which specific private color
was mixed in isn't a practical operation -- exactly mirroring the real
math's discrete logarithm problem, where recovering a private exponent
from a public exchanged value is computationally infeasible.

What forward secrecy means, and why it needs ephemeral values:

Forward secrecy means that even if an attacker later obtains a party's
LONG-TERM private key (say, by compromising a server years after a
conversation happened), that stolen key alone doesn't let them decrypt
past, already-completed session data.

This specifically requires EPHEMERAL (freshly generated, single-use,
then immediately discarded) private values, rather than reusing a
static long-term key for every session's DH exchange. If a static key
were reused for every session, then compromising that one static key
at any point in time would retroactively expose every past session
that ever used it -- because the same "private color" would have been
mixed into every single exchange, all derivable from that one
long-term secret. With ephemeral values, each session's private color
is generated fresh and thrown away right after use, so it was never
stored anywhere for a future attacker to later recover, even with
knowledge of the long-term key.

WHY THIS WORKS AS AN ANSWER
------------------------------
This walks the chapter's own analogy through every step explicitly
(rather than summarizing it), and then derives forward secrecy's
ephemeral-vs-static distinction directly from the analogy's own logic:
a static private color reused across sessions would make every past
session's secret derivable from that one persistent value, which is
precisely the property ephemeral (DHE/ECDHE) key generation removes.