English:Cryptography
Cryptography
Introduction
Cryptography is the science and engineering of protecting information and computation in the presence of adversaries. In modern systems, it does much more than hide messages: it supports confidentiality, integrity, authentication, secure key establishment, digital signatures, and many forms of privacy-preserving computation. You encounter cryptography when a browser establishes an HTTPS connection, a software package verifies an update, a messaging application protects a conversation, or a university service authenticates your login.
A central lesson of this course is that strong cryptography depends on more than choosing a famous algorithm. Security emerges from a chain that includes a clear threat model, sound primitives, secure modes and protocols, good randomness, correct key management, careful implementation, and appropriate operational practice. A mathematically strong primitive can still fail when a nonce is reused, a private key is exposed, a certificate is not checked, or a side channel leaks information.
The Enigma machine is historically important because it shows both the ingenuity of cryptographic design and the importance of operational weaknesses, key management, and cryptanalysis. Historical systems are valuable for learning, but they should not be confused with modern security.
Learning Goals
After completing this aiMOOC, you should be able to explain the major security goals of cryptography, distinguish important cryptographic primitives, reason about threat models and security assumptions, analyze common implementation failures, and select appropriate modern tools for a stated application. You should also be able to explain why secure protocol composition matters and how post-quantum migration changes the cryptographic landscape.
From Classical Ciphers to Modern Cryptography
Classical Ciphers and Cryptanalysis
Classical ciphers usually transform letters or symbols according to a fixed rule. A Caesar cipher shifts each letter by a constant number of positions. A substitution cipher replaces symbols according to a substitution alphabet, while a transposition cipher changes positions without changing the symbols themselves. These systems are useful for learning about keys, plaintext, ciphertext, and cryptanalysis, but they do not provide meaningful security against modern attackers.
Classical cryptanalysis exploits structure and redundancy in natural language. Frequency analysis, known-plaintext information, and repeated patterns can reveal the transformation used by simple ciphers. This leads to a foundational design principle associated with Auguste Kerckhoffs: a cryptosystem should remain secure even when everything about the system except the key is public. Modern cryptography therefore treats public algorithms and public scrutiny as strengths rather than weaknesses.
Perfect Secrecy and the One-Time Pad
The one-time pad is a useful theoretical benchmark. If the key is uniformly random, at least as long as the message, kept secret, and never reused, the resulting scheme has information-theoretic secrecy: the ciphertext alone reveals no information about the plaintext. The practical difficulty is key generation, distribution, storage, and strict one-time use.
The one-time pad illustrates a recurring theme: a security theorem depends on assumptions. If the same pad is reused, those assumptions fail and relations between messages may become visible. In practical cryptography, you should always ask which assumptions a security claim requires and whether the real system satisfies them.
Security Goals and Threat Models
What Cryptography Tries to Protect
Confidentiality means preventing unauthorized disclosure of information. Integrity means detecting unauthorized modification. Authentication means establishing a claim about an entity or message origin with suitable assurance. Non-repudiation is sometimes used for systems where signed records can support later dispute resolution, although legal and operational meaning goes beyond mathematics alone. Forward secrecy limits the damage of a later long-term key compromise by protecting previously established session keys.
These goals are different. Encryption alone does not automatically provide integrity or authenticity. A hash value alone does not authenticate a sender. A digital signature does not hide a message. Good system design begins by identifying which goals are required.
Adversaries, Assumptions, and Security Models
A threat model describes what an adversary can observe, modify, query, steal, or control. In network settings, a strong model often assumes that an attacker can read, block, replay, reorder, and inject traffic. Security should not depend on an attacker being unaware of the algorithm.
Modern cryptography formalizes security through games and reductions. For encryption, notions such as indistinguishability under chosen-plaintext attack and chosen-ciphertext attack capture increasingly powerful adversarial capabilities. For digital signatures, existential unforgeability under chosen-message attack is a standard goal. You do not need to memorize every formal definition immediately, but you should understand why precise adversarial models are more useful than vague claims that a scheme is "hard to break."
Mathematical and Theoretical Foundations
Probability, Entropy, and Security Parameters
Cryptographic reasoning uses probability because randomized key generation, randomized encryption, and adversarial success are probabilistic phenomena. A security parameter describes how the resources required for an attack grow as parameters increase. Formal security arguments often require an efficient adversary's probability of success to become negligible as the security parameter grows.
Entropy measures uncertainty in a random variable, but not every source with apparent variability is suitable for key generation. Cryptographic randomness must be unpredictable in the relevant threat model. This distinction matters for passwords, hardware noise sources, pseudorandom generators, and key-generation systems.
Algebraic Structures and Hard Problems
Many public-key constructions use modular arithmetic, finite groups, finite fields, or elliptic curve groups. Their security relies on computational problems believed to be difficult for the intended class of adversaries. Classical examples include integer factorization and the discrete logarithm problem. Post-quantum schemes use different mathematical foundations, including structured lattices, hash-based constructions, and error-correcting codes.
A hard mathematical problem is not automatically a secure cryptosystem. A construction must also resist attacks created by its interface, encoding, randomness, protocol context, and implementation. Security reductions help connect a successful attack on a construction to a supposedly hard underlying problem, but the exact assumptions and attack model matter.
Symmetric-Key Cryptography
Block Ciphers and AES
In symmetric-key cryptography, communicating parties share secret key material. Symmetric primitives are typically fast and are widely used for bulk data protection. The Advanced Encryption Standard is a block cipher standardized by NIST. AES processes 128-bit blocks and supports 128-, 192-, and 256-bit keys.
AES internally applies repeated transformations to a state. The SubBytes step substitutes each byte through a nonlinear substitution box. Other round operations provide diffusion and key mixing. The security of an application, however, depends not only on the AES primitive but also on how it is used.
Modes, Nonces, and Authenticated Encryption
A block cipher must be embedded in a mode of operation to protect messages longer than one block. ECB mode independently encrypts equal plaintext blocks into equal ciphertext blocks under the same key and therefore leaks patterns; it is generally unsuitable for ordinary data confidentiality.
Counter mode converts a block cipher into a stream-like construction, but its nonce and counter inputs must not repeat under the same key. Galois/Counter Mode, or GCM, is an authenticated-encryption mode. It can protect both confidentiality and integrity while also authenticating associated data that remains unencrypted.
Modern protocols frequently use authenticated encryption with associated data, abbreviated AEAD. AEAD combines encryption and authentication in a single construction with a precise interface. Nonce requirements are part of that interface, not optional advice.
Stream Ciphers
A stream cipher generates a pseudorandom keystream that is combined with plaintext. Modern examples include ChaCha20, commonly paired with Poly1305 for authentication as ChaCha20-Poly1305. Reusing a keystream or nonce inappropriately can destroy confidentiality, so APIs should make safe nonce handling explicit.
Public-Key Cryptography and Key Establishment
Public and Private Keys
Public-key cryptography uses mathematically related public and private key material. A public key may be distributed, while the corresponding private key must remain secret. Public-key techniques support tasks such as encryption, digital signatures, and key establishment, but a specific algorithm does not necessarily support every task.
RSA historically became a major public-key system. Secure use requires standardized padding and encoding schemes; "textbook RSA" is not a safe application protocol. In contemporary systems, public-key operations are often used to authenticate peers or establish session secrets, while symmetric AEAD protects bulk traffic.
Diffie-Hellman Key Exchange
The Diffie-Hellman key exchange allows two parties to derive shared secret material over a public channel without first sharing that secret. Its classical security is related to the difficulty of discrete logarithm problems in the chosen group. By itself, unauthenticated Diffie-Hellman does not prove who the peer is and is vulnerable to a man-in-the-middle attacker who establishes separate secrets with both sides.
Authenticated protocols combine ephemeral key exchange with certificates, digital signatures, pre-shared keys, or another authentication mechanism. Ephemeral Diffie-Hellman can support forward secrecy because a later compromise of a long-term authentication key need not reveal old ephemeral session secrets.
Hybrid Encryption and Key Encapsulation
Public-key operations are relatively expensive, so practical systems often combine public-key and symmetric cryptography. In a hybrid design, public-key techniques establish or encapsulate shared secret material, a key derivation function derives context-specific keys, and a symmetric AEAD scheme protects the actual application data.
A key encapsulation mechanism uses a public key to create a ciphertext-like encapsulation and shared secret, while the private key holder decapsulates to obtain the same secret. This KEM concept is especially important in post-quantum cryptography and modern protocol design.
Cryptographic Hash Functions and Message Authentication
Hash Functions
A cryptographic hash function maps data of arbitrary practical length to a fixed-length digest. Important security goals include preimage resistance, second-preimage resistance, and collision resistance. For an ideal n-bit hash, generic collision search takes about 2^(n/2) work because of the birthday effect, while generic preimage search takes about 2^n work.
SHA-2 and SHA-3 are modern standardized hash families. MD5 and SHA-1 should not be chosen for collision-resistant applications because practical collision attacks are known. Hash functions support integrity checking, signatures, Merkle structures, commitment constructions, and many protocol components.
A Merkle tree organizes hashes hierarchically so that membership or consistency claims can be checked with a compact authentication path instead of retransmitting every data item. This pattern appears in authenticated data structures, transparency systems, distributed systems, and several cryptographic protocols.
MACs and HMAC
A message authentication code uses a secret key to produce an authentication tag. A valid tag gives a party that knows the key evidence that the protected data was not modified and was generated by someone with access to that shared secret. HMAC is a widely used construction that combines a cryptographic hash function with a secret key.
A plain hash is not a substitute for a MAC when an active attacker can alter both the message and its hash. Authentication requires a secret or a public-key verification mechanism that the attacker cannot forge.
Passwords, Salts, and Key Derivation
Human-chosen passwords have limited and uneven entropy, so they should not be stored as ordinary fast hashes. Password storage normally uses a salted, deliberately expensive password-hashing or key-derivation function such as Argon2, scrypt, or PBKDF2, configured according to current guidance and system constraints. A unique salt prevents identical passwords from automatically producing identical stored values and reduces the usefulness of precomputed tables.
A key derivation function can also turn shared secret material into one or more cryptographic keys with context separation. Protocols commonly derive distinct keys for different directions or purposes rather than reusing one key everywhere.
Digital Signatures and Public-Key Infrastructure
Digital Signatures
A digital signature allows a holder of a private signing key to create a value that anyone with the corresponding public verification key can check. Signature security aims to make forgery infeasible even when an attacker has seen signatures on other messages. Digital signatures support software updates, certificates, document workflows, and many authentication protocols.
A digital signature is not the same as encryption. Signing provides authenticity and integrity properties, while encryption is designed for confidentiality. Secure systems often need both, but each should be used through a standardized construction and protocol.
Certificates and Trust
A public key certificate binds identity information to a public key through a signature by a certificate issuer. Web PKI uses certificate authorities, certificate chains, hostname validation, expiration rules, and revocation mechanisms to help a client decide whether a public key is acceptable for a server identity.
Trust is therefore partly cryptographic and partly operational. A mathematically valid signature is useful only if the verifier has a justified reason to trust the verification key and correctly checks the relevant identity and policy.
Cryptographic Protocols: TLS as a Case Study
Composition Matters
A protocol combines primitives into a sequence of messages and state transitions. A protocol can be insecure even if every primitive is individually strong. Designers must consider message ordering, transcript binding, downgrade resistance, replay resistance, key separation, error handling, and state-machine behavior.
TLS 1.3 is a useful case study because it combines authenticated key establishment, key derivation, certificates or other authentication methods, and AEAD record protection. TLS 1.3 models its record protection through AEAD rather than separate encryption and MAC combinations.
TLS demonstrates a broader rule: do not invent a new cryptographic protocol unless there is a compelling reason and expert review. Prefer mature, widely analyzed protocols and well-maintained libraries.
Randomness, Keys, and Implementation Security
Cryptographically Secure Randomness
Keys, nonces, salts, and ephemeral secrets often depend on randomness. A cryptographically secure pseudorandom number generator should produce outputs that remain unpredictable to attackers even when they know the design. Weak or predictable randomness can collapse otherwise strong cryptography.
Entropy must come from suitable operating-system or hardware sources, and random-number generator state must be protected. Application code should normally use established cryptographic APIs rather than attempt to design a generator from scratch.
Key Lifecycle and Crypto-Agility
Key management includes generation, distribution, storage, rotation, backup where appropriate, revocation, destruction, and auditing. Long-lived private keys are high-value assets and may require hardware-backed protection or carefully controlled key-management systems.
Crypto-agility means designing systems so that algorithms, parameter sets, certificates, and keys can be upgraded without replacing the entire application. This matters when cryptanalysis improves, standards change, implementation flaws are discovered, or organizations migrate to post-quantum algorithms.
Side Channels and Implementation Failures
Real implementations leak through timing, cache behavior, power use, electromagnetic signals, error messages, memory handling, and other channels. Constant-time programming, side-channel-resistant libraries, memory safety, protocol hardening, and secure hardware can reduce these risks.
Common failures include nonce reuse, insecure random-number generation, unchecked certificates, hard-coded secrets, unsafe key reuse, outdated algorithms, incorrect padding, and accepting unauthenticated data before verification. The recurring lesson is that implementation and protocol discipline are part of cryptography, not separate from it.
Post-Quantum Cryptography
Why Quantum Computing Changes Public-Key Assumptions
A sufficiently capable fault-tolerant quantum computer running Shor's algorithm would threaten widely used public-key systems based on integer factorization and discrete logarithms, including RSA, finite-field Diffie-Hellman, and elliptic-curve cryptography. Grover's algorithm gives a quadratic speedup for generic search, which affects symmetric-key and hash security differently and can often be addressed by suitable parameter choices.
The risk is partly about data that must remain confidential for many years. An adversary can store encrypted traffic today and attempt decryption later if future technology makes the underlying public-key protection obsolete. This motivates migration before large cryptographically relevant quantum computers exist.
NIST Post-Quantum Standards
NIST finalized three principal post-quantum standards in August 2024: FIPS 203 for ML-KEM key encapsulation, FIPS 204 for ML-DSA digital signatures, and FIPS 205 for SLH-DSA hash-based digital signatures. As of 2026, NIST has also selected HQC for future standardization as an additional key-encapsulation mechanism based on different mathematical assumptions, while the FALCON-derived FIPS 206 signature standard remains in development.
Post-quantum migration is not simply an algorithm swap. Organizations need inventories of cryptographic dependencies, interoperability testing, performance evaluation, protocol updates, certificate and key-management changes, and plans for hybrid or staged deployment where standards and ecosystems require them.
Responsible Cryptographic Engineering
Cryptography protects people, institutions, research, commerce, and infrastructure, but it can also be misapplied. Responsible engineering includes minimizing sensitive data, applying least privilege, documenting threat models, using peer-reviewed standards, testing error paths, monitoring dependencies, and planning for incident response.
Security claims should be proportional to evidence. Avoid claims such as "unbreakable" unless a precise theorem and assumptions justify the statement. In practical systems, it is usually more informative to state which threat model is addressed, which standard or library is used, how keys are protected, and what residual risks remain.
Standards and Further Reading
- Advanced Encryption Standard: NIST FIPS 197 specifies AES-128, AES-192, and AES-256 with 128-bit blocks.
- Authenticated encryption: NIST SP 800-38D specifies GCM and GMAC.
- Secure Hash Algorithms: NIST FIPS 180-4 specifies the Secure Hash Standard family covered by that publication.
- Transport Layer Security: RFC 8446 specifies TLS 1.3.
- Post-quantum cryptography: NIST Post-Quantum Cryptography Project provides current standards and migration information.
- Cryptography: English Wikipedia gives a broad overview and links to historical and modern topics.
Interactive Tasks
Quiz: Test Your Knowledge
Which property is the main purpose of encryption? (Confidentiality) (!Integrity) (!Availability) (!Compression)
Why is ECB mode generally unsuitable for ordinary data confidentiality? (It reveals repeated plaintext patterns) (!It requires a public key) (!It cannot process binary data) (!It always changes message length)
What additional property does an AEAD construction provide besides confidentiality? (Integrity and authenticity) (!Data compression) (!Key recovery) (!Perfect secrecy)
What is a critical requirement for a one-time pad key? (It must never be reused) (!It must be public) (!It must be shorter than the message) (!It must contain only letters)
What does unauthenticated Diffie-Hellman fail to establish by itself? (Peer identity) (!A shared secret) (!Public parameters) (!Group operations)
Which statement about a cryptographic hash function is correct? (It maps input data to a fixed length digest) (!It requires the same secret key for all users) (!It always allows the message to be recovered) (!It provides confidentiality by itself)
Why is a plain hash insufficient for authenticating a message against an active attacker? (The attacker can alter both message and hash) (!The hash always contains the private key) (!The hash is longer than the message) (!The hash automatically encrypts the message)
What is the primary role of a digital signature? (To provide verifiable authenticity and integrity) (!To compress a message) (!To hide the message from every verifier) (!To generate random numbers)
Which long-term risk motivates post-quantum migration today? (Stored ciphertext may be attacked in the future) (!AES cannot process digital data) (!Hash functions require paper keys) (!Certificates cannot contain public keys)
Which design principle best supports crypto-agility? (Allow cryptographic components to be upgraded) (!Hard code one algorithm forever) (!Reuse one key for every purpose) (!Hide the algorithm from reviewers)
Memory Game
| Plaintext | Original readable data before encryption |
| Ciphertext | Data produced by an encryption operation |
| Nonce | Value intended to be unique for a specified cryptographic use |
| HMAC | Keyed construction for message authentication based on a hash function |
| Signature | Publicly verifiable value produced with a private signing key |
| Salt | Unique nonsecret value used to diversify password hashing |
| KEM | Mechanism that establishes shared secret material through encapsulation |
Drag and Drop
| Match the correct terms. | Topic |
|---|---|
| Confidentiality | Prevent unauthorized disclosure |
| Integrity | Detect unauthorized modification |
| Authentication | Establish a claim about origin or identity |
| Forward secrecy | Limit past-session exposure after later key compromise |
| Crypto-agility | Enable controlled migration to new cryptographic components |
Match each security property to the description that best captures its purpose. Then explain one system in which two or more of these properties are needed together.
Crossword Puzzle
| Ciphertext | What is the encrypted form of a message called? |
| Integrity | Which property concerns detecting unauthorized modification? |
| Nonce | What unique-use value is often required by an encryption mode? |
| Hashing | What process maps data to a fixed-length digest? |
| Signature | What cryptographic object can be verified with a public key? |
| Entropy | What term describes uncertainty used as a source for secure randomness? |
LearningApps
Cloze Text
Open-Ended Tasks
Easy
- Threat model sketch: Choose a university service such as online grading or course registration and draw a one-page threat model showing assets, trusted components, adversaries, and desired cryptographic properties.
- Cipher comparison: Encrypt a short sentence with a Caesar cipher and explain in a brief text why this historical technique is unsuitable for modern confidential communication.
- Hash observation: Use a trusted local hashing tool to hash two nearly identical files, record the two digests, and explain what the result shows about sensitivity to input changes without claiming that a hash is encryption.
- Media explainer: Create a two-minute video or narrated slide explaining the difference between encryption, hashing, and digital signatures for a non-specialist audience.
Standard
- Authenticated encryption design: Design a message format for a sensor application using an AEAD interface and justify what should be encrypted, what may be associated data, and how nonce uniqueness will be maintained.
- Certificate inspection: Visit a public HTTPS site, inspect its certificate information with your browser, and write a short report on the hostname, issuer, validity period, public-key type, and what the browser is actually trusting.
- Password storage review: Compare Argon2, scrypt, and PBKDF2 using current authoritative documentation and produce a decision matrix for a hypothetical university web application.
- Cryptography interview: Interview a system administrator, developer, or security practitioner about key rotation, certificate renewal, secrets management, or incident response and summarize the operational lessons.
Advanced
- Protocol analysis: Draw a simplified authenticated key-establishment protocol, identify each security goal and trust assumption, and analyze at least two plausible attacks that the protocol must prevent.
- Side-channel experiment: Implement a harmless timing experiment on your own code that compares an early-exit string comparison with a constant-work comparison, collect measurements, and discuss why timing differences can matter without targeting any external system.
- Post-quantum migration plan: Produce a cryptographic inventory and migration roadmap for a fictional university with web services, VPN access, code signing, archival data, and research systems, using current NIST post-quantum standards.
- Research critique: Select a peer-reviewed cryptography paper, identify its security model, assumptions, construction, evaluation method, and limitations, then present a five-minute critical seminar summary.
Learning Assessment
- Security goal analysis: Given a case in which student records are transmitted over an untrusted network, identify the required confidentiality, integrity, authentication, and forward-secrecy properties and justify each one.
- Nonce failure reasoning: Explain how violating a nonce-uniqueness requirement can undermine a scheme even when the underlying block cipher remains mathematically strong, and distinguish primitive security from system security.
- Protocol composition assessment: Analyze a hypothetical protocol that encrypts data but does not authenticate it, identify realistic consequences of active modification, and redesign the protocol using an appropriate authenticated construction.
- Key trust assessment: Compare possession of a public key with justified trust in that key, and explain how certificates, fingerprints, or pre-shared trust can change the conclusion.
- Cryptographic lifecycle plan: Propose a lifecycle for a long-lived signing key, covering generation, protection, use, rotation, revocation, audit, and eventual destruction.
- Post-quantum transfer task: Explain how the arrival of a cryptographically relevant quantum computer would affect RSA, elliptic-curve systems, symmetric encryption, and hash functions differently, then recommend a migration priority for a university environment.
Evidence of Learning
Evidence of learning should show that you can connect mathematical properties, protocol behavior, and operational practice rather than merely name algorithms.
Knowledge evidence includes accurate explanations of confidentiality, integrity, authentication, forward secrecy, symmetric and public-key cryptography, hashes, MACs, signatures, key derivation, TLS, and post-quantum standards.
Reasoning evidence includes a defensible threat model, explicit assumptions, analysis of attacker capabilities, and explanations of why a selected primitive or protocol satisfies the required goals.
Practical evidence includes artifacts such as a certificate analysis, AEAD message design, controlled hashing experiment, protocol diagram, timing experiment on your own code, or cryptographic inventory.
Communication evidence includes the ability to explain cryptographic trade-offs clearly to both technical and non-technical audiences without overstating guarantees.
Transfer evidence includes the ability to evaluate an unfamiliar system, identify cryptographic dependencies, recognize implementation risks, and propose a migration or remediation plan grounded in current standards.
OERs on the Topic
Linked Learning Areas
