Guth
NewsDocs
Page actions
View as Markdown ↗
Explore MCP tools ↗

instrument / verified-clean

SHA-256 / Hash Function Demo

The current ledger marks this instrument verified clean within the source-bound verification corpus.

Status: VERIFIED_CLEANLifecycle: verified-clean

Inspectable records

Ledger state

The current ledger marks this instrument verified clean within the source-bound verification corpus.

Area
Computing & Information
Tranche
tranche-4
Evidence ID
t4-064
Ledger rows
1

No ledger note is attached.

Review findings

The SHA-256 standard is appropriate for the claimed educational computation, and the existing honest label correctly identifies MD5 and SHA-1 as cryptographically broken. The specification needs the exact preprocessing, encoding, complete SHA-256 algorithm definition, and explicit definitions for the optional algorithms and avalanche comparison before it can receive PASS.

Formula and scope findings

  • The stated formula identifies the SHA-256 compression function but does not specify the complete hash procedure: UTF-8 or byte encoding, Merkle-Damgard padding, 64-bit message-length encoding, initial hash values, message schedule, 64 rounds, and final state-word addition are all required to compute a digest.
  • The optional SHA-1 and MD5 comparison modes have no formulas or exact algorithm specifications. SHA-1 is covered by FIPS 180-4, but MD5 is not.
  • The avalanche-effect comparison is an output feature, not a defined formula; the changed-input construction and comparison metric must be specified. A simple digest inequality is not a quantitative avalanche measure.

Unit assumptions

  • Text inputs are encoded as UTF-8 bytes with no BOM, and the digest is computed over those exact bytes.
  • File inputs are hashed as their raw bytes without text decoding or newline normalization.
  • The message length is measured in bits and encoded as an unsigned 64-bit big-endian integer during SHA-256 padding.
  • Digest output is lowercase hexadecimal, with two hex characters per byte.
  • The implementation uses 32-bit unsigned arithmetic modulo 2^32, including additions, rotations, and shifts.

Boundary hardening

BREAK_CLAIMED · SELF_FLAGGED

The extreme-length vector reaches the SHA-256 domain limit and must be rejected; otherwise the 64-bit length field wraps to zero and the result is not standard SHA-256. The specification also leaves hex-letter case unspecified, creating a representation-compatibility hazard.

Errata and corrections

No applied erratum is attached to this unique-name record.

Inspectable example

4 review vectors are recorded. One source-bound sample is shown below.

{
  "inputs": {
    "algorithm": "SHA-256",
    "text": ""
  },
  "expected_outputs": {
    "hex_digest": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
  },
  "working": "1. UTF-8 bytes: 0 bytes. 2. Bit length: 0 x 8 = 0 bits. 3. Pad one 0x80 byte, then 55 zero bytes, then append the 64-bit big-endian length 0x0000000000000000: 1 + 55 + 8 = 64 bytes, so there is one 512-bit block. 4. Initialize the standard SHA-256 state and apply the 64 compression rounds to that block. 5. Add the resulting working words to the initial state modulo 2^32. 6. Concatenate the eight final 32-bit words: e3b0c442 || 98fc1c14 || 9afbf4c8 || 996fb924 || 27ae41e4 || 649b934c || a495991b || 7852b855 = e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855."
}

Related workflows

Sources and evidence

These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.

  • VERIFIED_LEDGER.json · VERIFIED_CLEAN
  • evidence-tranche4/tranche4-results.json
  • BOUNDARY_HAZARD_CATALOG.json