A CSS containing block is the reference rectangle used by applicable layout rules to determine a box's size and position. Which ancestor establishes it, and which edges define it, depend on the positioning and layout context. It is therefore not simply another name for the immediate parent DOM element.^[ref][ref]

Consider a horizontal block with position: relative; width: 300px; padding: 20px; border: 5px solid and content-box sizing. Its content width is $300$ and its padding-box width is $340$ CSS pixels. An ordinary block child whose width is 50% uses the applicable $300$-pixel content-width reference, giving $150$ pixels. A child with position: absolute; width: 50% instead uses this positioned ancestor's padding-box reference, giving $170$ pixels. Assume no intervening ancestor establishes another reference, and no child padding, borders or other size constraints.^[ref]

The same percentage text thus produces different numbers because its geometric reference changes. This is useful when debugging an apparently wrong width: first identify the actual CSS containing block, then apply CSS box-sizing and the remaining constraints.

A CSS containing block does not automatically confine all descendant painting. Content may extend beyond it; CSS overflow and clipping rules are separate. A positioning reference, a clipping boundary and a DOM tree parent need not identify the same rectangle or object.

A CSS inline-block box participates as one unit in its parent's CSS inline formatting context while providing a CSS block container for its own contents. It can therefore sit beside text or other inline-level boxes while containing independently laid-out text and blocks. The outer and inner layout roles are separate.^[ref]

For example, two cards each have a CSS border box width of $80$ CSS pixels, zero margins and an intervening space that occupies $10$ pixels. Their combined width is $80+10+80=170$ pixels. They can share an available line width of $180$ pixels, but not $160$ pixels under these assumptions. Text inside either card can wrap within that card; the surrounding line treats the card as one unit instead of dividing it into several fragments.

Declaring display: inline-block; width: 80px also makes width applicable to an ordinary non-replaced element that would otherwise have generated an inline box. Check CSS box-sizing before deciding whether the eighty pixels describe its content or border dimensions.

CSS vertical alignment determines placement within the surrounding line. A gap beneath an inline-block can consequently concern baseline alignment rather than a mysterious extra margin. Source whitespace between cards can also occupy inline space. Diagnose these effects using the outer line layout and the card's internal CSS block formatting context separately.

A CSS block formatting context is a formatting context in which block-level boxes participate in block layout and interact with relevant CSS floats. A box establishing a new context gives its contents an independent layout context. This is distinct from simply being a CSS block container or an ordinary block-level box.^[ref]

CSS flow-root, selected by display: flow-root, explicitly creates a block container establishing a new CSS block formatting context. An ordinary CSS inline-block box similarly combines an inline outer role with an independent flow context for its contents.^[ref]

A useful controlled layout experiment gives a parent width: 200px; height: auto; margin: 0; padding: 0; border: 0 and only one child, with float: left; width: 80px; height: 60px; margin: 0. With no other content or constraints, compare ordinary display: block with display: flow-root on the parent. The ordinary parent's content height is zero in this setup; the context-establishing parent's content height includes the sixty-pixel float. The child remains floated in both cases. This is a predicted result of the stated layout rules, rather than a browser timing measurement.^[ref][ref]

Margins do not collapse across the context boundary, but eligible margins of sibling blocks inside it can still collapse. For example, adjoining internal bottom/top margins of twenty and thirty CSS pixels can still give a thirty-pixel separation. Establishing a context is therefore not a universal switch disabling CSS margin collapsing.^[ref][ref]

Finally, CSS flow-root itself does not request clipping or a scrollbar. Treat formatting isolation, CSS containing block geometry and CSS overflow as separate properties of the layout.

CSS overflow concerns content or painting extending beyond a box's assigned region and the properties controlling its clipping and scrolling. The distinction between the box's size and the extent of its contents is essential: restricting a box does not necessarily make every descendant smaller.^[ref]

For example, a zero-padding container has content width $100$ CSS pixels, while a child has width $150$ pixels and begins at its left edge. The child extends fifty pixels beyond the container. The container's declared width can remain $100$ even when more of the child is painted.

With both axes set to overflow: visible, overflow is not clipped by that property. overflow: hidden clips and does not expose ordinary scrolling controls, but can still permit programmatic scrolling. overflow: clip forbids scrolling altogether and does not create a CSS scroll container. overflow: auto supplies scrolling behavior when needed under its rules.^[ref]

These choices can also affect layout. On an applicable block box, scrollable overflow values establish an independent formatting context. The non-scrollable clip value alone does not; display: flow-root can separately establish a CSS block formatting context. A request to clip and a request to isolate formatting consequently need not be the same declaration.^[ref]

CSS overflow does not delete overflowing DOM nodes. Clipped content can still exist in the document, and a scrollbar is not a replacement for checking whether important information remains accessible in the intended medium. Also distinguish a glyph or shadow painting beyond its nominal bounds from a larger scrollable content region; the specification defines ink and scrollable overflow separately.

The crystal violet cation is the positively charged organic component of the crystal violet salt. Its molecular formula is ${\mathrm{C}}_{25}{\mathrm{H}}_{30}{\mathrm{N}}_3^{+}$, with net charge $+1$. The complete chloride salt additionally contains a chloride counterion; the isolated organic cation does not contain a chlorine atom.^[ref]

The cation contains three substituted aromatic rings and nitrogen-containing groups in a conjugated system. A drawn charged Lewis structure is a representation of that electronic system, rather than a claim that the molecular charge is a classical point permanently confined to the atom carrying the printed plus sign. Resonance distinguishes alternative electronic representations from different chemical substances.

An original mass check uses the ChEBI average masses $372.536\mathrm{g}\mathrm{mo}{\mathrm{l}}^{-1}$ for the cation and $407.989\mathrm{g}\mathrm{mo}{\mathrm{l}}^{-1}$ for the chloride formula unit. Their difference, $35.453\mathrm{g}\mathrm{mo}{\mathrm{l}}^{-1}$, is the chloride contribution under that atomic-mass convention. For $1.00\mathrm{mmol}$ of ideal anhydrous salt, the sample contains $1.00\mathrm{mmol}$ of dye cations and $1.00\mathrm{mmol}$ of chloride ions; the total sample mass is $407.989\mathrm{mg}$, not $372.536\mathrm{mg}$.

The organic cation accounts for about $372.536/407.989\simeq 91.31\%$ of that ideal salt's mass. Confusing the two molar masses therefore changes an amount calculation even when the desired number of dye ions is specified correctly. This stoichiometric distinction does not itself predict dye binding, solution speciation or the crystal violet biomass response.

A crystal violet biomass response is a staining signal from material retained through a crystal violet assay's handling steps. In an adherent cell culture, it can track retained cellular material, but its interpretation as living cell number requires additional assumptions about adhesion, staining and recovery.

A primary protocol describes crystal violet binding to proteins and DNA in attached cells. Detachment during cell death can remove material before measurement, reducing the signal; the authors explicitly require additional methods to identify the cause of reduced staining.^[ref] This is an indirect readout, rather than a dye reaction that intrinsically counts every living cell.

An original linear model writes the blank-corrected absorbance aswhere $N$ is the number of relevant cells before handling, $f_{\mathrm{ret}}$ the fraction retained, $\overline{q}$ the average retained stain per retained cell, and $K$ the extraction and optical conversion factor. The last equality is an aggregate definition, not proof that different cells bind equal amounts of dye.

Suppose a matched control gives $B=0.80$ from 10000 cells. A treated preparation with the same initial number but half retained gives $B=0.40$ if the other factors stay fixed. A second preparation with 5000 cells, all retained and the same per-cell response, gives the same signal. Doubling retained stain per cell while halving retained number would instead preserve the original signal. These chosen examples demonstrate different explanations of one optical observation.

A dilution or cell number series can test a chosen linear response range. It does not establish invariant staining per cell after a treatment that changes cell size, protein content, attachment or material lost in washing. Independent counting or a validated cell viability readout addresses information missing from the stain signal alone.

The distinction is experimentally important when comparing dye methods. Primary work found lower crystal violet cell-number readouts but increased MTT formazan formation under kaempferol treatment, followed by cell-free tests of direct tetrazolium interference.^[ref] Agreement or disagreement between assays must be interpreted through their different measurement mechanisms.

A fractional crystallographic coordinate is one of the dimensionless coefficients expressing a position in the basis of specified unit cell vectors:The three coefficients are also called fractional crystal coordinates. Reporting them requires specifying the cell vectors and origin. The core CIF coordinate items store these fractions rather than Cartesian lengths.^[ref]

For an original orthorhombic example, let the mutually perpendicular cell edges have lengths4,6 and8 angstroms. The fractional position $(1/4,1/2,1/8)$ has Cartesian coordinates $(1,3,1)$ angstroms. Adding an integer to one fractional coordinate selects the corresponding translated position in another cell; it does not change the motif's location relative to the repeating cell.

For an oblique cell, multiplying the fractions by edge lengths is insufficient to obtain Cartesian components. In a two-dimensional example, take $\mathbf{a}=(2,0)$ and $\mathbf{b}=(1,\sqrt{3})$ angstroms. The fractional position $(1/2,1/2)$ isThe crystallographic metric matrix $G_{ij}={\mathbf{a}}_i\cdot {\mathbf{a}}_j$ records the necessary lengths and angles. A displacement with fractional column vector $\mathbf{u}$ has squared length ${\mathbf{u}}^{T}G\mathbf{u}$. Applying the ordinary Cartesian distance formula directly to the fractions would discard the geometry of the crystal structure.

Fractional crystal coordinates are the dimensionless coefficients in $r=u{a}_1+v{a}_2+w{a}_3$ for specified unit cell vectors. They are not Cartesian lengths unless the vectors themselves are included. With primitive vectors, replacing $u,v,w$ by values differing by integers selects an equivalent position in another unit cell.

In the two-dimensional example under crystal structure, B has position $(0.65,0.55)$ in ordinary length coordinates, but fractional crystal coordinates $(0.65/2,0.55/1.5)=(13/40,11/30)$. Multiplying these coefficients by the two translation vectors recovers the drawn position. Reporting the axes is therefore part of reporting a structure.

A known-answer test checks a cryptographic implementation by supplying fixed, completely specified inputs and comparing its output with an independently established expected value. The input and expected output together form a cryptographic test vector; the test is the act of executing the implementation and checking that agreement. Published HMAC vectors explicitly support conformance testing.^[ref]

For example, take the four key bytes 4a 65 66 65, representing Jefe, and the 28 ASCII message bytes representing what do ya want for nothing?. The published HMAC with SHA-256 result is

5bdcc146bf60754e6a042426089575c75a003f089d2739839dec58b964ec3843.

A known-answer test decodes that 64-digit hexadecimal value to 32 expected bytes, computes the keyed result, and compares all 32 bytes. Neither the message's terminating string-storage zero nor a newline is part of these input bytes.^[ref]

Several different errors can cause failure: decoding hexadecimal as text, including an extra byte, using the wrong key, selecting another cryptographic hash function, or serializing the result incorrectly. A failure establishes disagreement with the vector; it does not identify the responsible step by itself. A useful test harness reports the selected function, input lengths and first differing output position.

Passing also has a precise limit. A defective implementation that returns this expected value for this one input and zero for every other input passes this test. Thus a finite set of known-answer tests is evidence about those cases, not a proof of correctness for all inputs or a proof of cryptographic security. Boundary cases complement ordinary short examples: the primary vector set includes output truncation and keys longer than a hash's input block.^[ref]

An independently fixed expected value is essential. Computing the “expected” output with the same implementation under test can reproduce the same defect on both sides. Known-answer tests are especially useful for reproducible checks of exact byte conventions across different implementations.

A zero-knowledge proof is a proof protocol that convinces a verifier of a public statement's validity while revealing no additional information that the verifier could not efficiently obtain from that statement and its permitted prior information. The formal comparison uses a zero-knowledge simulator: an efficient randomized algorithm that reproduces the verifier's view without the prover's secret cryptographic witness.^[ref]

An interactive proof system separates three questions. Completeness of an interactive proof asks whether an honest prover can convince the verifier of a true statement. Soundness of an interactive proof bounds acceptance of false statements. Zero knowledge concerns information disclosure, so a protocol can pass a soundness test without being zero knowledge. The simulator comparison may require equality of distributions, statistical closeness or computational indistinguishability, depending on the definition.^[ref]

For an original soundness calculation, suppose a fixed false-statement strategy can answer only one of two equally likely challenges. Its acceptance probability is at most $1/2$. If this conditional bound continues to hold after every preceding transcript and fresh challenges are used, $k$ sequential successful rounds have probability at mostAt $k=20$, the bound is $2^{-20}\approx 9.54\times 10^{-7}$. This stipulated calculation does not prove that any particular protocol has the required per-round bound, nor does it establish zero knowledge.

The simulator supplies the separate privacy argument. It must reproduce the relevant distribution efficiently, rather than merely output one accepting transcript. A zero-knowledge proof can be interactive or a non-interactive zero-knowledge proof; its precise verifier and setup assumptions are part of its security claim.

A common reference string is public setup data shared by the parties to a cryptographic protocol. Its distribution is specified by the cryptographic setup. In a non-interactive zero-knowledge proof, the prover and verifier can use the same string $\sigma$ without exchanging a new challenge during each proof.^[ref]

A common random string is the special case in which the setup string is uniformly sampled; more general reference-string models specify another efficiently generated distribution. Being public is compatible with its purpose: the cryptographic witness may be secret even though the reference string is available to everyone.

An original eight-bit example shows why format and distribution are distinct. A uniform eight-bit string satisfiesA generator that always outputs those eight zeros satisfies the same length requirement but gives that event probability one. Checking length alone cannot establish the intended sampling law. This example illustrates a distributional distinction, not a proposed secure setup.

The zero-knowledge simulator may also simulate the joint distribution of setup data and proof. Consequently, the definition must state how setup is generated and what generation-related information the relevant parties possess. A public string with the right shape is not by itself evidence for the security properties of a proof system.^[ref]

A cryptographic witness is auxiliary information $w$ that satisfies an efficiently checkable relation for a public statement $x$. Writing the relation as $R(x,w)=1$ separates the claim from the information that certifies it. In a zero-knowledge proof, a prover may use such a witness without revealing it.^[ref]

For an original graph isomorphism example, let the public graphs $G$ and $H$ both be the path with edges $\{1,2\},\{2,3\}$. A witness is a bijection of vertices preserving adjacency. Bothandare valid. A witness need not be unique. With an adjacency-matrix encoding, a verifier can check all vertex pairs and their images in $O(n^2)$ comparisons for an $n$-vertex pair.

The public assertion is that a suitable mapping exists; the witness supplies one particular mapping. Whether that mapping is secret depends on the application. Calling it a witness does not inherently make it a password or a secret key.

A further distinction concerns what a proof establishes. Soundness of an interactive proof protects against acceptance of false statements. A proof of knowledge requires an additional formal relationship between a successful prover and extraction of a witness. Validity of a statement and knowledge of its certificate are not interchangeable claims.

A proof of knowledge is a proof protocol whose success is linked to an efficient procedure for obtaining a cryptographic witness from the prover's behavior. The procedure is a knowledge extractor, with access to the prover specified by the definition. The ordinary verifier in an interactive proof need not receive the witness during the real exchange.^[ref]

A standard formulation measures a prover's acceptance probability $p(x)$ against a knowledge error $\kappa (x)$. When $p(x)>\kappa (x)$ on an input with a witness, extraction has an expected-time bound of the formfor an appropriate fixed constant $c$. The relation, oracle access and false-input guarantees must also be specified; this expression alone is not the complete definition.^[ref]

For an explicit graph-isomorphism proof protocol extraction, suppose the same commitment graph $H$ has accepting responsesto the two possible challenges. The compositionis a graph isomorphism, hence a witness for the public claim. Rewinding in cryptographic proofs can provide the extractor with differently challenged continuations of a common earlier state.

The formula explains a knowledge claim without invoking a human notion of understanding. Soundness of an interactive proof and zero-knowledge proof privacy are separate requirements: excluding false statements and hiding information do not by themselves establish extraction.

Cryptographic setup is the generation and distribution of initial parameters or other resources required by a cryptographic protocol. Its specification includes the input cryptographic security parameter, the sampling procedure, the public output and any information that must remain secret. Setup is part of the protocol's security model, rather than an arbitrary source of well-formatted constants.

A common reference string gives one example. Parties to a non-interactive zero-knowledge proof may share a public string $\sigma$ sampled by the prescribed setup. The definition describes both its distribution and how that setup participates in real and simulated proof experiments.^[ref]

An original distribution example makes the generation rule explicit. Let a toy setup sample two independent uniform bits $a,b$ and publishIts support is $\{000,011,101,110\}$, each with probability $1/4$. A uniformly sampled three-bit string instead has eight possible values, each with probability $1/8$. The two generators publish strings of the same length, but the second satisfies the parity equation only half the time.

This toy setup is not a secure proof-system construction. It demonstrates why replacing a specified generator by a different random-looking source changes the experiment. Public availability of setup data and correctness of its generation are separate properties.

A cryptographic security parameter is an integer $\lambda$ indexing a family of cryptographic protocols or algorithms. It controls the scale at which efficiency and security guarantees are stated. Theoretical algorithms are often given $1^{\lambda }$, a string of $\lambda$ ones, so polynomial time in that input length means polynomial time in $\lambda$.^[ref]

A typical asymptotic guarantee requires a cryptographically negligible probability: for every fixed $c>0$, the relevant probability eventually falls below ${\lambda }^{-c}$. An exponential such as $2^{-\lambda }$ has that property; $1/\lambda$ does not, because it fails the requirement for $c=2$.

An original idealized guessing example separates a parameter from a concrete security claim. If a secret is uniform among $2^{128}$ possible values and no other information about it is supplied, one fixed guess succeeds with probability $2^{-128}$. Checking $q$ distinct guesses covers at most a fractionof those possibilities. This is a counting argument under the stated uniform-secret model, not a guarantee for every scheme described as having a128-bit key.

The parameter's numerical value, key length, algorithmic cost and actual adversary advantage are related through the particular construction. Naming the parameter alone does not establish a concrete work estimate or compensate for a flaw in the protocol.

Universal composability is a framework for specifying and proving security of cryptographic protocols so that their guarantees survive the framework's protocol-composition operation. It compares a real implementation with an ideal cryptographic functionality describing the intended service, permitted leakage and adversarial influence. Ran Canetti's primary work develops the composition guarantee, including concurrent executions.^[ref]

The comparison uses a cryptographic simulator in the ideal execution and a cryptographic environment trying to distinguish the executions. Schematically, in the computational formulation,Here $A$ is the real adversary, $S$ the simulator, $Z$ the environment, $z$ an auxiliary input and $\lambda$ the cryptographic security parameter. The participants have the specified computational bounds, and ${\approx }_c$ denotes computational indistinguishability. The simulator is chosen for the adversary before universally quantifying over environments; a different simulator chosen after seeing each environment would be a weaker requirement.^[ref]

An original distinguishing example shows why permitted leakage belongs in the specification. Suppose an ideal channel hides a message's length before delivery, but a proposed real implementation exposes that length. An environment privately selects a uniform bit $b$ and supplies an honest sender a one-byte message if $b=0$ or a two-byte message if $b=1$. It asks the adversary to guess $b$ before the honest recipient supplies any output. Visible length lets a real adversary guess perfectly. An ideal simulator receiving no length or content information can guess only with probability $1/2$. The environment accepts when the guess equals its private bit, giving a probability gap $1/2$.

That mismatch can be addressed by changing the implementation, for example with suitable padding, or by specifying the intended length leakage in the ideal service. The two choices describe different security properties. Correctly delivering messages does not by itself resolve the distinction.

The composition theorem permits replacing an ideal-service call by a protocol that realizes that service, under the theorem's interface and execution-model conditions. This supports modular proofs: a larger protocol need not reanalyse the lower-level implementation from scratch.^[ref] The guarantee belongs to the modelled setup, identities and allowed interactions; an isolated confidentiality game is not automatically a proof of universal composability.

A cryptographic transcript is the specified record of messages exchanged during a cryptographic protocol execution. Its content depends on the purpose: a public communication record differs from a participant's complete private view, which can also include its input, secret state and randomness. Order, message boundaries and the identities or roles associated with messages can matter.

For a concrete standardized use, Transport Layer Security 1.3 authenticates a transcript hash computed from selected handshake messages in their prescribed order. It includes handshake type and length headers, but excludes record-layer headers. Its retry path specifies a special replacement for the first client message.^[ref]

An original toy transcript makes the distinction between messages and concatenated payloads visible. Suppose a sender transmits ab and then c. The payload sequence is $(\mathtt{ab},\mathtt{c})$. Another execution transmits a and then bc. Both flatten to ASCII bytes 61 62 63, even though they have different first messages. A length-prefixed encoding preserves the distinction as 02 61 62 01 63 versus 01 61 02 62 63. A hash cannot recover boundaries that were omitted before hashing.

Direction can be equally important. The records “initiator sends yes” and “responder sends yes” contain identical payloads but assert different behavior. A format used to authenticate those assertions must bind the relevant roles, either explicitly in the encoded record or through an unambiguous protocol context. This toy rule is not a replacement for the TLS transcript format.

In a security proof, the observer's view and its correlations must be specified. A cryptographic simulator that samples messages with correct individual frequencies may still produce the wrong joint probability distribution with the cryptographic environment's retained inputs. A cryptographic transcript also discloses only the observations it records: a transcript omitting timing cannot by itself justify a security claim against timing observations.

A transcript hash is a compact fingerprint of the encoded record under the relevant cryptographic hash function assumptions. An unkeyed hash alone does not identify the speaker: a digital signature or message authentication code must bind it to an authenticated context when that is the intended guarantee.

A cryptographic leakage function specifies which observation of secret state is disclosed in a model. A deterministic version writes $L=\ell (X)$, where $X$ is a secret random variable. It is a description of an observer's information, not an encryption algorithm. An ideal cryptographic functionality can explicitly send permitted disclosures to its cryptographic simulator; Canetti's secure-communication example permits disclosure of message length.^[ref]

For an observed value $l$ of positive probability, possible secrets lie in its preimage under $\ell$. Their posterior probabilities areEqual likelihood within that set requires a uniform prior there; it is not a consequence of the word leakage.

An original example takes $X$ uniform on all eight-bit strings and lets $\ell (X)$ be its Hamming weight. The disclosure has only nine possible values, but its consequences vary. If $L=4$, there are $\left(\genfrac{}{}{0ex}{}{8}{4}\right)=70$ equally likely secrets and the best exact guess succeeds with probability $1/70$. If $L=0$, the secret is certainly the all-zero string. A rare disclosure can therefore determine the complete secret even though the observation is encoded in only four bits.

Averaging optimal exact-guess success over all disclosed weights givescompared with $1/256$ before observation. This Hamming-weight leakage of a uniform bit string distinguishes an average guessing probability from the worst conditional outcome.

Specify repeated observations and any correlated side information too. Two individually limited disclosures can jointly identify a secret. A randomized or noisy observation is described by a conditional channel rather than only a deterministic function. Stating an allowed cryptographic leakage function makes a security claim precise; it does not establish that the disclosure is harmless for every application.

SHA-2 is a family of cryptographic hash functions including SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256. NIST specifies these algorithms in FIPS 180-4. Their digest lengths are respectively 224, 256, 384, 512, 224 and 256 bits; the algorithm name therefore matters as well as the output size.^[ref]

The SHA-224/SHA-256 branch uses 32-bit words and 512-bit message blocks. The SHA-384/SHA-512 branch and its specified truncation variants use 64-bit words and 1024-bit message blocks. Different initial values are part of the definitions. In particular, SHA-512/256 is not simply the first 256 bits of an ordinary SHA-512 digest.^[ref]

For a computed example, hashing the three ASCII bytes 61 62 63 with SHA-512/256 produces

53048e2681941ef99b2e29b76b4c7dabe4c2d0c634fc6d46e0e2f13107e7af23.

Taking the first 256 bits of the SHA-512 digest of those same bytes instead gives

ddaf35a193617abacc417349ae20413112e6fa4e89a97ea20a9eeee64b55d39a.

Both outputs occupy 32 bytes and require 64 hexadecimal digits, yet they differ. An interface identifying its hash only as a 256-bit digest leaves the selected algorithm ambiguous.

A digest is deterministic and does not conceal low-entropy inputs by itself. Nor does an unkeyed digest establish who supplied a message: a sender-authentication mechanism such as HMAC uses a cryptographic key and an appropriate security definition. Preimage resistance, second-preimage resistance and collision resistance are distinct properties; their meanings should not be replaced by the mere observation that two displayed examples have different outputs.

A hash initialization vector is the initial internal state from which a specified cryptographic hash function begins processing a message. For the SHA-2 algorithms, it is a public, algorithm-defined sequence of state words. It is not a fresh per-message cryptographic nonce, a secret key or a cryptographic salt.^[ref]

For an iterative hash, write the state update schematically aswhere $M_i$ is one padded message block and $C$ is the algorithm's hash compression function. The digest is derived from the final state by the algorithm's output rule. Initial state, padding, compression and output rule together specify the function; agreeing on only the output width does not specify a hash.

An original comparison uses two specified algorithms. SHA-256 starts with the 32-bit word 6a09e667, while SHA-224 starts with c1059ed8. Both subsequently use the SHA-256-family compression structure, but their full initial states differ. Even the empty message is padded and processed, so its digest is not simply a printed initial state.^[ref]

Computing the empty-message digests gives SHA-256

and SHA-224

d14a028c2a3a2bc9476102bb288234c415a2b01f828ea62ac5b3e42f.

Keeping the first 28 bytes of the first result does not produce the second. Initialization acts before every subsequent block transformation; final truncation cannot substitute for it.

This also matters when implementing several hash variants with one compression routine. Resetting a context must restore the chosen variant's complete initial state and length counters. Accidentally reusing a previous message's final state computes a different function. A known-answer test for empty and short messages can expose such state-management mistakes, although passing finitely many vectors does not prove every update sequence correct.