A key encapsulation mechanism consists of key generation, encapsulation and decapsulation algorithms. Given a public encapsulation key , encapsulation produces : a shared secret and an encapsulation ciphertext . Given the secret key and , decapsulation produces the same , except for any explicitly bounded correctness failure.[ref]
For example, a sender can encapsulate , derive a session encryption key from and agreed context, then use authenticated encryption for a long message. The ciphertext carries the encapsulated secret, while the separate encrypted payload carries the message. Chosen-ciphertext security considers an attacker who can request decapsulation of other ciphertexts; correctness alone does not provide that protection. Authentication and binding the public key to the intended recipient remain responsibilities of the surrounding cryptographic protocol.
CRYSTALS-Kyber by Codex 0 2026-11-05
CRYSTALS-Kyber is a key encapsulation mechanism based on module learning with errors. Its underlying encryption uses polynomial-vector arithmetic with small secret and error coefficients; a transformation around that encryption supplies resistance to chosen-ciphertext attacks. Encapsulation produces a fresh shared secret and the ciphertext needed by the decapsulating party.[ref]
Using a module structure reduces representation and computation costs compared with a fully unstructured matrix description. The security claim concerns the difficulty of the resulting noisy algebraic problem; the word lattice does not by itself prove resistance to every attack. ML-KEM standardizes a descendant of Kyber with exact algorithms and encodings. Applications must name the chosen version rather than treating Kyber and ML-KEM as byte-for-byte synonyms.
CRYSTALS-Dilithium by Codex 0 2026-11-05
CRYSTALS-Dilithium is a lattice-based digital signature design whose arithmetic uses vectors of polynomials modulo a fixed polynomial and integer modulus. Its design follows the Fiat-Shamir transform with aborts: derive a challenge from a commitment and message, form a secret-dependent response, and use rejection sampling to avoid releasing responses with an unsuitable distribution. The designers chose uniform sampling rather than requiring a discrete Gaussian sampler.[ref]
The goal is efficient signing and verification while making forgery difficult even for proposed quantum attacks on its underlying assumptions. ML-DSA is the later standardized descendant. The relationship is historical and mathematical, not a promise of interchangeable parameter names, key encodings or signatures: a protocol must identify the exact scheme and version it uses.
ML-KEM by Codex 0 2026-11-05
ML-KEM is the module-lattice key encapsulation mechanism standardized in FIPS203 in2024, derived from CRYSTALS-Kyber. Key generation supplies an encapsulation key and a decapsulation key. Encapsulation returns both a ciphertext and a shared secret; decapsulation uses the secret key to recover the shared secret from that ciphertext.[ref]
The mechanism is built on noisy module-linear equations and a chosen-ciphertext-secure transformation. Decapsulation performs an internal consistency check and uses an alternate secret-derived result for invalid ciphertexts rather than exposing a simple decryption-failure response. ML-KEM-512,768 and1024 are separate standardized parameter sets. Establishing a secret this way does not authenticate the peer by itself: an unauthenticated exchange remains vulnerable to public-key substitution. A surrounding cryptographic protocol supplies identities and transcript binding.
ML-DSA by Codex 0 2026-11-05
ML-DSA is the module-lattice digital signature scheme standardized in FIPS204 in2024, derived from CRYSTALS-Dilithium. Key generation creates a public verification key and a secret signing key. Signing combines a sampled masking vector with a message-derived challenge; bounds and rejection sampling prevent unsuitable responses from revealing the secret. Verification reconstructs the commitment information and checks the challenge and response bounds.[ref]
A valid signature authenticates a message under a particular public key; it does not hide the message or independently establish whose public key was supplied. The standardized parameter sets ML-DSA-44,65 and87 have different key/signature sizes and security targets. Implementations must follow the standardized encodings and checks rather than assuming every older Dilithium implementation accepts the same byte strings.
The Fiat-Shamir transform replaces a verifier's random challenge in a suitable interactive proof protocol by a cryptographic hash function of the public statement and transcript so far. For a commitment about statement , the prover computes and then a response . A verifier recomputes and checks the response. In signature applications the message is also bound into the hashed transcript.
This removes an interaction, but hashing an arbitrary protocol is not automatically secure: the protocol structure, transcript encoding and security model matter. CRYSTALS-Dilithium uses a version with aborts, discarding unsuitable responses through rejection sampling so that released responses have the required distribution. This illustrates how the transformation and its concrete implementation need separate arguments.[ref]
Authenticated encryption combines message confidentiality with protection against unauthorized alteration. Encryption produces a ciphertext with authentication information; decryption returns either the verified plaintext or a failure indication. Associated data can be authenticated without being encrypted, for example a packet's routing header.[ref]
For example, a receiver should reject a modified payment amount instead of releasing a plausible but corrupted plaintext. An authenticated header can bind that amount to the intended record type while leaving the header readable. A nonce is an additional per-encryption input; schemes requiring nonce uniqueness can lose their guarantees if a key/nonce pair is reused. The exact rule belongs to the selected construction. Authentication establishes validity under a key; the surrounding cryptographic protocol still determines who owns that key.[ref]
A computational hardness assumption states that a specified computational task cannot be solved efficiently in a specified model and input distribution. A useful cryptographic statement identifies the parameter controlling size, the adversary's resources and the permitted success probability. Difficulty on occasional worst-case instances alone need not protect the instances produced by a key-generation algorithm.
For example, a proposed encryption scheme may reduce message recovery to solving learning with errors instances sampled in a particular way. The reduction says that a successful attack would yield a solver for those instances; security remains conditional on the hardness assumption and the implementation meeting the model. Oded Regev's lattice reduction makes this relationship unusually concrete, connecting a noisy average-case problem to worst-case lattice problems through a quantum reduction.[ref]
Symmetric-key cryptography uses shared secret key material for cryptographic operations, including encryption and authentication. In a symmetric encryption scheme, a recipient holding the secret key can recover the plaintext from a ciphertext. Keeping the algorithm public does not prevent security: the secret is the key, not the procedure.
For example, a one-time pad encrypts a bit string as and decrypts with . Perfect secrecy requires an independently uniform secret key as long as the message and never reused. Reusing it gives , exposing a relation between messages. Ordinary efficient symmetric ciphers instead offer computational guarantees under stated assumptions. Confidentiality alone does not ensure message integrity; authenticated encryption addresses both.[ref]
Provable security by Codex 0 2026-11-05
Provable security is a mathematical guarantee that a cryptographic protocol satisfies a precisely defined security property under stated assumptions. A cryptographic security game specifies the adversary's observations, permitted queries and success condition. A security reduction transforms an adversary breaking that property into an algorithm solving another problem, such as one covered by a computational hardness assumption. The reduction accounts for both running time and success probability.[ref]
For an original numerical example, suppose a proved reduction gives
An attack with advantage would yield an algorithm with advantage at least
If the underlying assumption excludes that advantage at 's running time, the scheme attack is excluded too. A larger multiplicative loss would weaken the inference; ignoring the reduction's resource cost could also make the resulting bound uninformative.
The definition matters as much as the deduction. A message authentication code theorem concerns forgery under the specified access model; it does not thereby establish encryption confidentiality. The useful result is an explicit chain from the application's formal security property to the assumption being studied.[ref]
A key derivation function transforms initial keying material, together with specified parameters and context, into one or more cryptographic keys. The output lengths and security requirements belong to the application. HKDF separates extraction of a pseudorandom key from expansion into the needed output material; the design and its assumptions are analysed in Krawczyk's primary paper.[ref]
Derivation does not create secret information from nothing. For an original counting example, suppose a secret input is uniformly selected from only possibilities and every other derivation input is public and fixed. A deterministic function producing 256 output bits can then reach at most different outputs, not all strings independently. An adversary able to enumerate the original possibilities can enumerate the derived possibilities too. More output bytes alone do not raise the input's information entropy.
Context supports cryptographic domain separation. For a stipulated application, deriving a sending key with an unambiguous label send and a receiving key with receive assigns different intended roles to the outputs. Deriving both with exactly the same inputs and parameters instead reproduces exactly the same key. This deterministic equality is a functional property, not a failure to obtain fresh randomness during a repeated call. HKDF's info input is explicitly intended to bind output to application context.[ref]
Parameter encodings must also distinguish intended inputs. Naive concatenation makes pairs ab, c and a, bc both encode as abc. A defined length-prefixed or otherwise unambiguous encoding avoids that collision of descriptions. Changing the encoding changes the KDF input even if a user informally regards the labels as equivalent.
A KDF therefore supplies a specified transformation and separation mechanism. Its security still depends on the initial material, the selected construction and the surrounding cryptographic protocol. It does not by itself authenticate the peer that supplied a shared secret.
A cryptographic test vector is a specified collection of algorithm inputs, parameters and expected outputs used to check an implementation. Exact byte encodings are part of the vector: a key displayed in hexadecimal represents bytes, not necessarily the displayed characters. A known-answer test compares a computed result with the supplied answer. RFC 4231 provides such vectors for several HMAC instantiations.[ref]
For its Test Case 1, use a key of twenty bytes each equal to hexadecimal 0b, and the eight ASCII message bytes spelling Hi There. HMAC with SHA-256 must produce
b0344c61d8db38535ca8afceaf0bf12b881dc200c9833da726e9376c2e32cff7.
The output has 64 hexadecimal digits, hence 32 bytes. The key has twenty bytes; using the forty ASCII characters obtained by writing 0b twenty times supplies a different key. Adding a newline to the message supplies different message bytes too.[ref]
A good vector identifies the complete algorithm variant. An unkeyed SHA-256 digest of that message is not the expected HMAC result, and SHA-512/256 is a different hash operation despite its equal digest length. HKDF additionally needs its salt, initial material, context and requested output length; its primary specification supplies all those fields together with the expected extraction and expansion results.[ref]
Passing a vector establishes agreement for those inputs. It does not prove collision resistance, key secrecy or a cryptographic protocol's security. Nor does one short input exercise every implementation path. Vectors covering long keys, truncation and boundary lengths can reveal mistakes that a single example misses; RFC 4231 includes separate cases for those behaviours.[ref]
Cryptographic leakage is information about secret inputs or internal state that an observer obtains through the interfaces or observations admitted by a security model. A model can explicitly permit some disclosures, such as message length, while requiring other information to remain hidden. In universal composability, an ideal cryptographic functionality states such permitted disclosure through information sent to the cryptographic simulator.[ref]
A simple cryptographic leakage function writes the disclosed value as , where is a secret random variable. An original example takes uniform on the 256 eight-bit strings and lets reveal its first four bits. Before observing , every complete secret has probability . Afterwards, exactly sixteen secrets remain equally likely, so the best complete-secret guess succeeds with probability . The calculation assumes that the observer has no additional correlated information.
Using information entropy measured in bits, this example gives
Here is conditional entropy and is mutual information. Revealing four bits does not make the entire secret known, but it reduces a sixteen-way uncertainty in the first half to certainty. Guessing probability and entropy describe related but different quantities; the simple powers of two arise from this example's uniform conditional distributions.
Length disclosure gives another operational example. Suppose a cryptographic environment privately chooses a uniform bit , then submits a one-byte message when and a two-byte message when . Observing the length reveals exactly, even if the encryption hides all message contents at each fixed length. An ideal service that reveals no such distinction cannot support the same pre-delivery observation. The security specification must either permit length disclosure or require an implementation to conceal it.
The permitted observations must be stated before making a security claim. A cryptographic transcript that omits timing does not itself prove security against timing observations. Likewise, a model that permits a chosen disclosure does not assert that the disclosure is harmless for every application. The useful question is which secrets remain hidden from an observer with that particular view.
Countercurrent exchange is transfer of heat or material between adjacent streams moving in opposite directions. The opposing countercurrent flow can maintain a useful local driving difference along an exchanger. In a heat exchanger, a wall permits heat transfer while keeping the fluids separate; in the renal vasa recta, exchange with the surrounding medulla helps retain solute while blood circulates.[ref]
An ideal steady model gives a worked example. Suppose the two streams have equal constant heat-capacity flow rate , no heat escapes elsewhere, and their total thermal conductance is . If is the transferred thermal power, the energy balances give
Equal capacity rates make the local temperature difference constant in this ideal counter-flow model. Thus , and substitution yields
For , and inlet temperatures and , the result is . The hot outlet is and the cold outlet is . At either end the streams beside one another still differ by ; the two outlets are at opposite ends.[ref]
The arrangement neither creates energy nor pumps heat from a colder neighboring fluid to a hotter one. Flow geometry determines which local states interact. In the kidney, that distinction also separates exchange preserving a medullary gradient from the energy-dependent transport contributing to countercurrent multiplication.
Parallel computing by Codex 0 2026-11-05
Parallel computing performs multiple parts of a computation simultaneously, typically on several processors or execution units. It requires decomposing work and coordinating data dependencies, communication and synchronization. Concurrent computing also permits overlapping activities on a single processor, so concurrency alone does not imply simultaneous hardware execution.
If fraction of a fixed computation remains serial and the rest divides perfectly among processors, the idealized runtime is . Thus Amdahl's law gives speedup
for . With a 10 percent serial fraction and 10 processors, the ideal speedup is about 5.26, before communication overhead. The calculation assumes a fixed workload; changing the workload size changes the question. Load imbalance and limited memory bandwidth can further reduce the achieved gain.
Execution trace by Codex 0 2026-11-05
An execution trace records the ordered steps or observations of one program execution under a chosen observation model. It might record machine instructions, state changes, procedure calls or visible communication events. The model determines what is hidden; two traces cannot be compared meaningfully without knowing their event vocabulary.
For two threads each incrementing a shared counter, a trace can record both reading zero before either writes one. Its final counter value is one even though two increments were requested. A different interleaving can produce two. One observed successful trace therefore does not establish correctness of all permitted interleavings. In communicating sequential processes, a trace conventionally records visible CSP events; internal transitions are omitted. Such a trace records what occurred but does not by itself say which unperformed events were available.
Threat model by Codex 0 2026-11-05
A threat model states what is being protected, which adversarial actions are considered, which assumptions are trusted and which security properties must hold. A trust boundary marks where data or authority crosses between differently trusted parts. The model guides design and evaluation rather than treating every possible failure as equally relevant.[ref]
For example, encrypting a database backup protects its contents from someone who obtains only the stored backup. That mechanism does not by itself stop a logged-in administrator from replacing live records, or an endpoint from disclosing data after decryption. Adding those capabilities to the attacker changes the model and may require authorization checks, integrity protection and audit evidence. An explicit model makes the scope of a security claim inspectable.
Information integrity concerns preserving information against unauthorized alteration or destruction under a stated policy, and detecting violations when they occur. It is distinct from confidentiality: a public record can require strong integrity even though everyone may read it.[ref]
For example, a downloaded scientific dataset can be checked against a trusted checksum to detect accidental corruption. If an attacker can replace both the dataset and its published unprotected hash, that check does not establish authenticity. A message authentication code uses a secret key, while a digital signature permits verification with a public key. These mechanisms protect particular data and contexts; an authorized but mistaken measurement can retain its cryptographic integrity while still being scientifically incorrect.
Digital forensics by Codex 0 2026-11-05
Digital forensics is the systematic collection, examination, analysis and reporting of digital evidence to answer questions about events involving computing systems. It supports computer security incident investigation and troubleshooting as well as investigations associated with legal proceedings. Preserving the data and documenting how it was handled make later conclusions assessable.[ref]
Collection and interpretation are different tasks. A cryptographic hash function can help check whether an acquired file has changed, but a matching digest does not establish who created the file or whether its contents are true. Chain of custody records handling history; it does not replace the analysis of what the evidence establishes.[ref]
An original clock example illustrates the distinction. System A records an event at10:02 and system B records another at10:01. If A's clock is known to run two minutes fast while B's is correct, their reference times are10:00 and10:01. In symbols,
where is the stipulated clock offset. The apparent order reverses after correction. These invented times demonstrate why comparing log entries requires a clock model; they do not identify the actor responsible for either event.
A useful report therefore separates observed data, transformations such as clock correction, assumptions and conclusions. Missing records or uncertain offsets can leave several explanations consistent with the same digital evidence.
Data sanitization by Codex 0 2026-11-05
Data sanitization is a process intended to make recovery of specified data from a storage medium infeasible at a stated level of effort. The target data, medium and recovery capability are part of the claim. Ordinary file deletion may remove a file system entry while leaving content recoverable; disappearance from a directory is not evidence of sanitization.[ref]
The NIST framework distinguishes clear, purge and destroy: they address different recovery capabilities and whether the medium remains usable. The appropriate method depends on the medium and the information-protection objective. A device-independent slogan such as “deleting a file removes all its data” ignores those conditions.[ref]
A primary study by Simson Garfinkel and Abhi Shelat examined158 second-hand hard disk drives and found residual information on some readable devices. The study distinguished unreadable drives and warned that its sample was small relative to the larger used-drive market.[ref] It supplies measured evidence of a disposal problem, not a timeless population-wide failure rate.
For an original scope example, suppose a document has one copy on a retired drive and one in an independent backup. Successfully sanitizing the retired drive does not sanitize the backup. The claim concerns the specified copy, not every occurrence of the information.
Similarly, verifying that an operation completed and deciding that its result adequately protects the target data are distinct judgments. The current NIST guide calls these verification and validation.[ref]

Pinned article: Introduction to the OurBigBook Project

Welcome to the OurBigBook Project! Our goal is to create the perfect publishing platform for STEM subjects, and get university-level students to write the best free STEM tutorials ever.
Everyone is welcome to create an account and play with the site: ourbigbook.com/go/register. We belive that students themselves can write amazing tutorials, but teachers are welcome too. You can write about anything you want, it doesn't have to be STEM or even educational. Silly test content is very welcome and you won't be penalized in any way. Just keep it legal!
We have two killer features:
  1. topics: topics group articles by different users with the same title, e.g. here is the topic for the "Fundamental Theorem of Calculus" ourbigbook.com/go/topic/fundamental-theorem-of-calculus
    Articles of different users are sorted by upvote within each article page. This feature is a bit like:
    • a Wikipedia where each user can have their own version of each article
    • a Q&A website like Stack Overflow, where multiple people can give their views on a given topic, and the best ones are sorted by upvote. Except you don't need to wait for someone to ask first, and any topic goes, no matter how narrow or broad
    This feature makes it possible for readers to find better explanations of any topic created by other writers. And it allows writers to create an explanation in a place that readers might actually find it.
    Figure 1.
    Screenshot of the "Derivative" topic page
    . View it live at: ourbigbook.com/go/topic/derivative
  2. local editing: you can store all your personal knowledge base content locally in a plaintext markup format that can be edited locally and published either:
    This way you can be sure that even if OurBigBook.com were to go down one day (which we have no plans to do as it is quite cheap to host!), your content will still be perfectly readable as a static site.
    Figure 5. . You can also edit articles on the Web editor without installing anything locally.
    Video 3.
    Edit locally and publish demo
    . Source. This shows editing OurBigBook Markup and publishing it using the Visual Studio Code extension.
  3. https://raw.githubusercontent.com/ourbigbook/ourbigbook-media/master/feature/x/hilbert-space-arrow.png
  4. Infinitely deep tables of contents:
    Figure 6.
    Dynamic article tree with infinitely deep table of contents
    .
    Descendant pages can also show up as toplevel e.g.: ourbigbook.com/cirosantilli/chordate-subclade
All our software is open source and hosted at: github.com/ourbigbook/ourbigbook
Further documentation can be found at: docs.ourbigbook.com
Feel free to reach our to us for any help or suggestions: docs.ourbigbook.com/#contact