Exercise 3: What Two Case Studies Have in Common Structurally — Possible Solution
====================================================================

Chosen pair: Enigma (Chapter 4, 1930s-40s) and Sony's ECDSA nonce
reuse (Chapter 10, 2010).

On the surface, these two cases could hardly look more different: one
is a mechanical rotor cipher machine used for military communication
during a world war; the other is a modern elliptic-curve digital
signature scheme protecting a consumer video game console's firmware,
separated by roughly 70 years and built on completely unrelated
mathematics (permutation-based substitution vs. elliptic curve
algebra).

What they share structurally:

1. THE UNDERLYING CRYPTOGRAPHIC DESIGN WAS SOUND. Enigma's ~10^114
   keyspace (Chapter 3) was mathematically real; ECDSA itself is a
   legitimate, still-trusted signature algorithm today, used correctly
   by countless other systems. Neither failure came from the
   mathematics being wrong or too weak in principle.

2. THE FAILURE CAME FROM REUSING SOMETHING THAT WAS SUPPOSED TO VARY.
   Enigma's operators reused message keys and fell into predictable
   settings ("cillies") instead of varying them properly session to
   session. Sony's signing implementation reused the exact same random
   nonce for every single signature instead of generating a fresh one
   each time, as ECDSA's design explicitly requires. In both cases,
   the failure is the same SHAPE: a value that the underlying
   cryptographic scheme assumed would be different (or sufficiently
   unpredictable) each time was instead held constant or made
   predictable in practice.

3. THAT REUSE GAVE ATTACKERS A SHORTCUT AROUND THE MATH ENTIRELY. In
   neither case did the attackers need to defeat Enigma's or ECDSA's
   actual cryptographic strength directly -- Bletchley Park exploited
   the doubled/reused key structure (and cribs) rather than searching
   the full 10^114 keyspace; the PS3 key extraction exploited the
   reused nonce algebraically rather than attacking elliptic curve
   discrete logarithms directly. Both attacks bypassed the hard
   mathematical problem entirely by targeting an operational shortcut
   instead.

WHY THIS WORKS AS AN ANSWER
------------------------------
Both cases fit the exact pattern this chapter's closing table
states for every entry: "predictable settings/reuse... never the
underlying math" (Ch.4) and "nonce reuse, directly leaking the signing
private key" (Ch.10). Choosing a 1930s mechanical system and a 2010s
digital signature scheme specifically demonstrates the chapter's own
point that this failure pattern isn't tied to any one era or
technology -- it's a structural risk inherent to ANY system that
depends on a value staying secret, unpredictable, or non-repeating,
regardless of how the underlying mathematics is implemented.