Cryptographic Assumptions & Challenges

Section II: Cryptographic Primitives

Army Cyber Institute

April 9, 2026

Why These Topics Now? Scope & Objectives

• We’ve covered symmetric, asymmetric, hashing, signatures.

• Today: assumptions under pressure and new tools.

• Themes:

  • Real-world implementation failures
  • Quantum threats
  • Post-quantum cryptography,
  • Fully-homomorphic Encryption
  • Zero Knowledge Proofs

• Outcome: awareness and evaluation skills, not proofs.

Overall Slide Concept This opening slide establishes the lesson as a capstone on pressure points, emerging tools, and real implementation failures rather than another narrow primitive tutorial. It matters here because students need a frame for why these topics belong after hashing, symmetric crypto, and public-key crypto. Emphasize breadth, evaluation skills, and the idea that mature engineering means anticipating assumption failure.

Key Points - The lesson focuses on assumptions under pressure, not on deriving new proofs. - Quantum threats, migration planning, privacy tools, and implementation failures all affect real blockchain systems. - Students should leave asking better engineering questions, not just memorizing buzzwords.

Walkthrough None

Sources [1]; [2]

Cryptographic Assumptions Decay Over Time

• As attacks against algorithms evolve; difficulty to break ciphers falls.

• We must build hash/signature agility now.

• Plan migrations in protocols and apps.

timeline
  title From "Safe" to "Deprecated"
  1995 : SHA-1 standardized; RSA-1024 common
  2005 : Theoretical attacks on SHA-1 published
  2011 : SHA-1 deprecated in many standards
  2017 : Practical SHA-1 collision demonstrated
  202X : PQC standardization; migration planning

Overall Slide Concept This slide establishes that cryptographic security is time-dependent and that deprecation is part of responsible design, not an admission of defeat. It matters here because the rest of the lesson keeps returning to migration and agility rather than eternal trust in one primitive. Emphasize that standards age through both cryptanalysis and cheaper computation.

Key Points - Security margins shrink as attacks improve and hardware becomes cheaper. - Systems should be designed for algorithm agility rather than single-algorithm permanence. - Blockchain upgrades are especially hard because migration touches consensus and ecosystem coordination.

Walkthrough None

Sources [1]; [2]

Hash Fragility: Collision Resistance Isn’t Forever

• SHA-1 (1995-2017): Once a global standard, now entirely deprecated due to practical collision attacks (e.g., SHAttered).
• The Threat: Attackers can engineer two entirely different files (one benign, one malicious) that produce the exact same hash.
• The Impact: Systems often sign the hash, not the file itself. A signature generated for the benign file will perfectly validate the malicious one.
• The Fix: Migrate to modern, collision-resistant algorithms like SHA-256, SHA-512, or SHA-3.

Overall Slide Concept This slide establishes collision failure as a concrete example of how a once-trusted primitive can become unsafe in deployed workflows. It matters here because students should connect broken collision resistance to signatures, file integrity, and other higher-level systems. Emphasize that signing a weak digest can accidentally authorize a malicious twin.

Key Points - Practical collisions break workflows that assume one hash uniquely identifies one file. - Signed hashes are especially vulnerable when the hash function no longer resists chosen collisions. - Migration requires stronger hashes plus explicit algorithm identifiers and deprecation planning.

Walkthrough None

Sources [1]; [2]

Quantum Primer: Why It Matters for Cryptography

• Classical vs. Quantum: Classical computers use bits (0 or 1). Quantum computers use qubits, leveraging superposition and entanglement to represent complex, overlapping states.
• Exponential Speedup: Quantum algorithms use interference to solve specific structured math problems exponentially faster than any classical supercomputer.
• The Cryptographic Threat: Unfortunately, the mathematical foundations of RSA and Elliptic Curve Cryptography (ECC) are exactly the types of problems quantum computers excel at breaking.

The Timeline: While practical, large-scale quantum computers do not exist yet, the threat of “Harvest Now, Decrypt Later” makes this an immediate priority for long-lived secrets.

Overall Slide Concept This slide establishes why quantum computing matters specifically to cryptography rather than as a generic “faster computers” story. It matters here because the next two slides separate public-key collapse from symmetric security shrinkage. Emphasize that long-lived secrets can be harvested today for later decryption.

Key Points - Quantum algorithms target specific mathematical structures underlying current public-key systems. - Shor and Grover change very different parts of the threat model. - Harvest-now-decrypt-later makes migration urgent before practical machines fully exist.

Walkthrough None

Sources [1]; [2]

Shor’s Algorithm (1994): Breaking RSA and ECC

• The Mathematical Breakthrough: In 1994, Peter Shor proved that a quantum computer could efficiently factor large integers and solve discrete logarithms, effectively breaking RSA and ECC.
  • Breaking modern crypto requires millions of physical qubits with advanced error correction, which remains a monumental engineering challenge.
• The Mitigation: Proactively adopt Post-Quantum Cryptography (PQC) signatures and hybrid deployments.

Overall Slide Concept This slide establishes Shor’s algorithm as the reason RSA and ECC are not future-proof against sufficiently capable quantum computers. It matters here because many modern internet and blockchain identity systems depend on those exact assumptions. Emphasize that the risk is existential for classical public-key hardness, not just a modest speedup.

Key Points - Shor’s algorithm would make factoring and discrete logs efficient on a large enough quantum computer. - That threatens RSA, Diffie–Hellman, ECC, and many signature systems built on them. - Migration planning includes hybrid deployments, reduced key exposure, and post-quantum replacements.

Walkthrough None

Sources [1]; [2]

Grover’s Algorithm (1996)

• Lov Grover formulated a quantum algorithm that searches unstructured data spaces quadratically faster than any classical algorithm.
• This effectively halves the security bit-strength of symmetric encryption (like AES) and cryptographic hashes (like SHA). A 128-bit key provides only 64 bits of security against a quantum adversary.
• The Mitigation: double the key or hash length. Primitives like AES-256 and SHA-384/512 remain robust and future-ready in a post-quantum world.

Overall Slide Concept This slide establishes Grover’s algorithm as a more limited but still important quantum effect on symmetric cryptography and hashing. It matters here because students should not walk away thinking quantum computing breaks everything equally. Emphasize that the main response is stronger parameters, not abandoning symmetric primitives.

Key Points - Grover gives a square-root style search advantage rather than a full structural break. - Symmetric keys and digests therefore need larger sizes to preserve margins. - AES-256 and longer digests remain strong practical choices in that model.

Walkthrough None

Sources [1]; [2]

Post-Quantum Cryptography: The New Toolbox

• The Objective: Proactively replace vulnerable public-key systems (RSA, ECC) with mathematical problems that resist known quantum algorithms.
• The Candidates: Emerging standards rely on entirely new math, primarily lattice-based, code-based, hash-based, and multivariate cryptography.
• The Replacements: NIST is actively standardizing new algorithms specifically for Key Encapsulation Mechanisms (KEMs) and Digital Signatures.
• The Engineering Trade-offs: There is no free lunch. PQC algorithms typically demand significantly larger key sizes, bulkier signatures, or heavier computation than modern ECC.

Overall Slide Concept This slide establishes post-quantum cryptography as the replacement toolbox for the public-key assumptions quantum algorithms threaten. It matters here because students need to understand that migration is about changing hardness assumptions, not abandoning asymmetric cryptography altogether. Emphasize tradeoffs in size, performance, and ecosystem maturity.

Key Points - PQC replaces factoring and discrete-log assumptions with alternatives like lattices, codes, and hashes. - Different post-quantum families make different tradeoffs in key size, signature size, and speed. - Near-term deployments are likely to be hybrid rather than purely post-quantum from day one.

Walkthrough None

Sources [1]; [2]

Lattices: Intuition Without the Math

• A lattice is a complex, repeating, high-dimensional grid of points generated by a set of basis vectors.
• Mathematical challenges like finding the closest point (Shortest Vector Problem - SVP) or solving linear equations with intentional noise (Learning With Errors - LWE) are astronomically difficult to solve at large dimensions.
• The PQC Foundation: Unlike factoring (RSA), no efficient quantum algorithm exists to solve these lattice problems, making them the primary foundation for post-quantum encryption, signatures, and key encapsulation (KEMs).

Overall Slide Concept This slide establishes lattice problems as the current leading intuition for post-quantum cryptography without requiring deep mathematics. It matters here because many standardized candidates rely on these assumptions. Emphasize high-dimensional hardness and noisy equations as the conceptual replacement for factoring and discrete logs.

Key Points - Lattices can be pictured as high-dimensional grids generated by basis vectors. - Problems like SVP and LWE are believed hard even for quantum attackers at practical scales. - These assumptions now underpin many leading PQC encryption and signature schemes.

Walkthrough None

Sources [1]; [2]

PQC Migration in Blockchain Systems

• The Targets (Where to upgrade): Public keys are exposed in wallets, consensus validators, cross-chain bridges, and light clients. These are the primary targets for migration.
• The Strategy (How to upgrade): Deploy hybrid signatures (combining classical algorithms like ECDSA with a PQC algorithm) and introduce new address versions to allow a gradual, opt-in rollover without breaking legacy systems.
• The Engineering Challenges: PQC algorithms typically require significantly larger key sizes and higher computational verification costs. In blockchains, this directly translates to larger block sizes, higher transaction fees, and increased user experience complexity.

Overall Slide Concept This slide establishes what post-quantum migration would actually look like in blockchain systems rather than in abstract standards documents. It matters here because blockchain design magnifies signature size, verification cost, and address-format decisions. Emphasize inventory first: know where keys are exposed before choosing a migration path.

Key Points - Wallets, validator keys, bridges, and light-client proofs are major blockchain migration targets. - Hybrid signatures and versioned address formats support gradual rollout. - Larger signatures and heavier verification can directly affect block size, fees, and UX.

Walkthrough None

Sources [1]; [2]

Fully Homomorphic Encryption (FHE)

• The Concept: FHE enables systems to perform arbitrary computations directly on encrypted data without ever needing a decryption key.
• The Mechanism: When the owner decrypts the final ciphertext, the result perfectly matches the computation as if it had been performed on the plaintext.
• The Mathematical Breakthrough: While theorized in 1978, Craig Gentry’s 2009 breakthrough used lattice-based cryptography and bootstrapping (a method to “clean” computational noise from ciphertexts) to make unlimited homomorphic operations possible.
• Blockchain Relevance: FHE is the key to confidential smart contracts. It allows decentralized nodes to execute complex contract logic over entirely encrypted user data and account states, providing total privacy on a public ledger.

Overall Slide Concept This slide establishes FHE as a privacy tool that allows useful computation without revealing plaintext inputs. It matters here because students often hear privacy claims in blockchain contexts without seeing the underlying cryptographic idea. Emphasize that FHE is powerful but still operationally expensive.

Key Points - FHE lets a server compute on ciphertexts and return an encrypted result. - The decrypted output matches what would have been computed on plaintext. - Confidential smart contracts and private analytics are motivating application areas.

Walkthrough None

Sources [1]; [2]

FHE at a Glance

• Privacy by design: the server computes entirely on ciphertexts — it never sees any plaintext.
• Correctness: Dec(Eval(f, Enc(x))) = f(x) — the math guarantees the right answer.
• Bootstrapping: periodically refreshes noisy ciphertexts so unlimited operations remain possible.
• Trade‑off: heavy computation and memory cost, improving with optimization and hardware support.

Overall Slide Concept This slide establishes the FHE pipeline visually so students can distinguish the privacy promise from the cost tradeoff. It matters here because the prior slide states the idea, while this one shows the flow of encrypted computation. Emphasize correctness, hidden plaintext, and the role of bootstrapping in keeping the scheme viable.

Key Points - Data stays encrypted while the untrusted server evaluates functions on it. - Bootstrapping refreshes noisy ciphertexts so longer computations remain possible. - The main cost today is performance and parameter tuning, not lack of conceptual power.

Walkthrough 1. Encrypt plaintext inputs locally before sending them to the server. 2. Let the server evaluate the desired function directly on ciphertexts, refreshing noise when needed. 3. Decrypt the returned ciphertext to recover the correct plaintext result.

Sources [1]; [2]

Zero‑Knowledge Proofs: Prove Without Revealing

• Completeness: if the statement is true, an honest prover can always convince a verifier.
• Soundness: a cheating prover cannot convince the verifier of a false statement (except with negligible probability).
• Zero‑knowledge: the verifier learns nothing beyond the truth of the statement — no secrets, no witnesses.
• Interactive vs. non‑interactive: classical ZK requires back-and-forth challenges; SNARKs/STARKs collapse this into a single short proof verifiable by anyone.
• Blockchain relevance: ZK rollups (e.g., zkSync, StarkNet) use succinct proofs to compress thousands of transactions into one on-chain verification, preserving both scalability and correctness.

Overall Slide Concept This slide establishes the three defining properties of zero-knowledge proofs and links them to their blockchain relevance. It matters here because privacy and scalability discussions later in the course depend on understanding why a proof can convince without revealing a witness. Emphasize completeness, soundness, and zero-knowledge as a package.

Key Points - Completeness, soundness, and zero-knowledge describe what a valid proof system must guarantee. - Non-interactive forms like SNARKs and STARKs make public verification practical at scale. - ZK systems are useful for both privacy and compression of expensive computation.

Walkthrough None

Sources None

Ali Baba Cave: The Protocol

• Key insight: if Prover can always exit from the called side, they must know the secret. After 30 rounds the probability of successful deception is less than 1 in a billion.
• Digital analogy: replace the cave with a hash function or elliptic‑curve relation; replace shouting with a random challenge bit.

Overall Slide Concept This slide establishes the Ali Baba cave as an intuition pump for zero-knowledge before students encounter more formal blockchain proof systems. It matters here because the cave story makes repeated challenge-response soundness easy to picture. Emphasize that convincing transcripts do not necessarily reveal the secret itself.

Key Points - A prover who knows the secret can always respond to the verifier’s random challenge correctly. - A bluffer succeeds only with limited probability each round, which shrinks rapidly with repetition. - The verifier gains confidence in knowledge of the secret without learning the secret.

Walkthrough 1. Let the prover choose a path while the verifier cannot see which one was chosen. 2. Have the verifier request a specific exit path at random. 3. Repeat many rounds and observe that only a secret-knowing prover can answer consistently.

Sources None

Zero‑Knowledge in Blockchain Practice

• Privacy — shielded transactions: protocols like Zcash use zk-SNARKs to prove that a transaction is valid (inputs balance outputs, sender is authorized) without revealing sender, receiver, or amount on-chain.
• Privacy — selective disclosure: a user can prove a single attribute (“my balance exceeds $X”, “I am over 18”) derived from a private credential, sharing nothing else — enabled by ZK circuits over committed values.
• Scalability — ZK rollups: zkSync, StarkNet, and Polygon zkEVM batch thousands of transactions off-chain, then post a single succinct validity proof on Ethereum. Verification costs roughly the same gas regardless of batch size, dramatically cutting per-transaction fees.
• Scalability — light clients: a ZK proof of the chain’s consensus state lets a mobile wallet verify the latest block header without downloading the full chain history.
• Compliance — private audits: a business can prove to a regulator that all transactions satisfy AML/KYC rules without exposing counterparties or amounts, satisfying legal obligations while preserving commercial confidentiality.

Overall Slide Concept This slide establishes how zero-knowledge ideas become real blockchain systems for privacy, scalability, and selective disclosure. It matters here because students need to see ZK as an engineering tool rather than only a philosophical curiosity. Emphasize that proof systems can replace expensive on-chain re-execution.

Key Points - Shielded transactions use ZK to prove validity without exposing key transaction details. - ZK rollups compress many transactions into one succinct proof verified on chain. - Circuit bugs, setup assumptions, and proof-system choices are critical engineering risks.

Walkthrough None

Sources [1]; [2]

When Good Crypto Goes Bad: Milk Sad (CVE-2023-39910)

• Rule one: never substitute a general-purpose PRNG for a cryptographically secure one — the resulting key space is trivially brute-forceable.
• What happened: Libbitcoin Explorer’s bx seed command used std::mt19937 (Mersenne Twister) seeded with only 32 bits from the system clock to generate 256-bit wallet seeds.
• Consequence: users believed they had 2²⁵⁶ possible keys; in reality they had only ~4.3 billion (2³²) — enumerable in days on commodity hardware.
• Impact (July 2023): attackers swept 2,600+ wallets across Bitcoin, Ethereum, Solana, and others; approximately $900,000 in losses in a single coordinated campaign.
• Root cause: CWE-338 — wrong tool, wrong context. mt19937 is designed for simulations, not secrets.
• Lessons: use OS-provided CSPRNGs (/dev/urandom, getrandom(), BCryptGenRandom); treat key generation as a security boundary, not a convenience call; use audited libraries (libsodium, OpenSSL) that make the secure choice by default.

Overall Slide Concept This slide establishes Milk Sad as a cautionary case where excellent underlying cryptography failed because key material came from a disastrously weak generator. It matters here because students should internalize that entropy quality is part of the security boundary. Emphasize that the attack succeeded without breaking secp256k1 or SHA-256.

Key Points - Mersenne Twister seeded from a 32-bit clock timestamp is not suitable for wallet seed generation. - The real keyspace was tiny enough to brute-force on commodity hardware. - CSPRNG choice is a first-class security decision, not a minor implementation detail.

Walkthrough None

Sources [1]

Case Study: Linux.Encoder RNG Failure

• What it was: Linux.Encoder.1 (2015) — ransomware that encrypted web servers using AES keys derived from srand(time()), a clock-seeded PRNG with no real entropy.
• Why it collapsed: file modification timestamps narrowed the candidate seed to a few seconds; Bitdefender brute-forced it and released a free decryptor within days — without ever touching AES.
• The “fix” that wasn’t: a patched version iterated srand(h(h(...h(time())...))). Hashing a weak seed does not add entropy — it only obscures a still-guessable value.
• Blockchain relevance: smart contract randomness faces the same trap. block.timestamp, blockhash, or miner-controlled fields are observable and manipulable — using them as entropy sources for key generation, lotteries, or NFT reveals repeats this exact mistake on a public ledger.
• Root cause: CWE-335. The cipher was sound; the entropy feeding it was not. Use /dev/urandom, getrandom(), or a verifiable on-chain randomness oracle (e.g., Chainlink VRF).

Overall Slide Concept This slide establishes Linux.Encoder as another entropy-failure case study, reinforcing that a strong cipher cannot compensate for predictable key generation. It matters here because students often over-credit the algorithm and under-credit the entropy source. Emphasize that hashing a weak seed does not create new randomness.

Key Points - Time-seeded PRNG output collapses the key search space dramatically. - Observable timestamps can narrow brute-force windows even further in practice. - Entropy is a property of the seed source, not of how many times you hash it afterward.

Walkthrough None

Sources [1]

Case Study: CryptoDefense — Keys Left in Plain Sight

• What it was: CryptoDefense (2014) — Windows ransomware that correctly used RSA-2048 to encrypt victim files, then demanded payment for the decryption key.
• The mistake: the authors called the Windows CryptoAPI without understanding it. CryptGenKey stores generated keys in the user’s own key store under %AppData%\Microsoft\Crypto\RSA — fully accessible to the victim. The private key needed to decrypt was sitting on the machine the whole time.
• Root cause: correct algorithm, catastrophic key handling. Strong math is irrelevant if the private key is not protected.
• Blockchain relevance: this failure class is the leading cause of cryptocurrency losses. Exchange hot wallets storing private keys on internet-connected servers, developers hardcoding keys in deployed contracts, and users keeping seed phrases in plaintext cloud documents are all the same mistake — the cryptography is sound but the key boundary is not defended.
• Lesson: treat private keys as the single most sensitive asset in any system. Use hardware security modules (HSMs), hardware wallets, or OS-protected keystores; never leave keys reachable by an adversary who has already compromised the adjacent environment.

Overall Slide Concept This slide establishes CryptoDefense as the key-handling counterpart to the previous entropy failures: the algorithm and randomness were fine, but private-key storage was careless. It matters here because many high-value blockchain losses come from this exact operational class of mistake. Emphasize that cryptographic strength and key-boundary discipline are separate requirements.

Key Points - Strong algorithms do not help if the private key is left accessible on the compromised machine. - Key handling errors are often more catastrophic and more common than mathematical breaks. - Hardware wallets, HSMs, and protected keystores exist to defend this boundary.

Walkthrough None

Sources [1]

Putting It Together: Threats and Responses

Overall Slide Concept This slide establishes the synthesis map for the lesson: each threat undermines a specific security property, and each response targets that broken assumption. It matters here because students should leave able to classify failures by property, not only by headline. Emphasize the middle column logic: identify what property is under attack first.

Key Points - Good analysis names the broken property before jumping to a fix. - Hash agility, PQC migration, privacy tools, and implementation hygiene each answer different threat classes. - Implementation discipline is the most immediately actionable response area for practitioners.

Walkthrough None

Sources None

Key Takeaways

• Assumptions age—design for cryptographic agility.
  
• Prepare for quantum: adopt PQC and strengthen symmetric parameters.
  
• Leverage privacy tools: FHE and ZK are moving from theory to practice.
  
• Avoid DIY: sound hygiene beats clever hacks.

Overall Slide Concept This closing slide establishes the durable engineering habits the lesson wants students to carry forward. It matters here because the section ends not with a new algorithm but with a mindset about migration, privacy, and disciplined implementation. Emphasize evolution, standard tools, and avoidance of DIY cryptography.

Key Points - Assume cryptographic assumptions will age and design systems that can migrate. - Strengthen parameters and prepare for post-quantum transitions where needed. - Use audited libraries and good hygiene instead of clever custom cryptography.

Walkthrough None

Sources [1]; [2]

References

[1]

J. Katz and Y. Lindell, Introduction to Modern Cryptography, 3rd ed. Chapman and Hall/CRC, 2020. doi: 10.1201/9781351133036.

[2]

A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone, “Handbook of Applied Cryptography.” CRC Press, Aug. 07, 2011. Accessed: Oct. 23, 2025. [Online]. Available: https://cacr.uwaterloo.ca/hac/