Source: https://guthlabs.ai/docs/instruments/checksum-verifier/

instrument / verified-clean

# Checksum Verifier

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

Status: **VERIFIED_CLEAN**Lifecycle: **verified-clean**

## Inspectable records

[01**Overview**Purpose and lifecycle](<https://guthlabs.ai/docs/instruments/checksum-verifier/>)[02**Mechanism**Method and assumptions](<https://guthlabs.ai/docs/instruments/checksum-verifier/mechanism/>)[03**Implementation**Binding and validation](<https://guthlabs.ai/docs/instruments/checksum-verifier/implementation/>)[04**Qualification**Evidence and errata](<https://guthlabs.ai/docs/instruments/checksum-verifier/qualification/>)

## 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-076

**Ledger rows**: 1

No ledger note is attached.

## Review findings

The core operation is feasible offline in pure JavaScript, but the specification is not complete enough for an unconditional PASS. Define the exact CRC32 parameter set, UTF-8 and newline policy, checksum syntax and case policy, algorithm error behavior, and honest UI labeling. The UI should state that CRC32 and MD5 are legacy integrity checks rather than collision-resistant security hashes.

### Formula and scope findings

- CRC32 polynomial division is conceptually correct but underspecified: CRC-32 variant parameters must be fixed, including polynomial, initial value, input/output reflection, final XOR, and output width. The standard CRC-32/ISO-HDLC parameters are assumed below.

- Hash digest comparison is the correct comparison operation, but the digest formulas and exact algorithm variants are not explicitly specified. MD5 and SHA-256 should be defined as their standard algorithms with exact byte input.

- The specification does not define text encoding, newline normalization, file-byte handling, hexadecimal case handling, or whether surrounding whitespace is significant.

- The specification does not state required checksum lengths or behavior for malformed expected checksum strings and unsupported algorithms.

### Unit assumptions

- Text test inputs are encoded as UTF-8 with no implicit newline, whitespace trimming, or Unicode normalization.

- Files are hashed as their exact raw bytes.

- CRC32 means CRC-32/ISO-HDLC: polynomial 0x04C11DB7, reflected implementation polynomial 0xEDB88320, initial register 0xFFFFFFFF, reflected input and output, final XOR 0xFFFFFFFF, 32-bit lowercase hexadecimal output.

- MD5 output is 128 bits represented by exactly 32 lowercase hexadecimal characters.

- SHA-256 output is 256 bits represented by exactly 64 lowercase hexadecimal characters.

- Checksum comparison should be exact after validating hexadecimal syntax; if case-insensitive comparison is intended, that must be explicitly documented.

## Boundary hardening

**BREAK_CLAIMED** · SELF_FLAGGED

The specification does not define text encoding or whether hexadecimal checksum comparison is case-sensitive. The convention probe therefore produces match=true under the stated UTF-8, case-insensitive convention but strict case-sensitive comparison would produce mismatch=false for the same visible input and expected checksum.

## 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": "CRC32",
    "text": "123456789",
    "expected_checksum": "cbf43926",
    "encoding": "UTF-8"
  },
  "expected_outputs": {
    "computed_checksum": "cbf43926",
    "match": true
  },
  "working": "UTF-8 bytes: 31 32 33 34 35 36 37 38 39. Initialize CRC register = FFFFFFFF. Apply the reflected CRC-32 recurrence for all 9 bytes using polynomial EDB88320. Register after the final byte = 340BC6D9. Apply final XOR: 340BC6D9 XOR FFFFFFFF = CBF43926. Format as 8 lowercase hexadecimal characters: cbf43926. Compare cbf43926 with cbf43926: equal, so match = true."
}
````

## Related workflows

[Crypto & Number Theory Classroomintegrity 2](<https://guthlabs.ai/docs/instrument-workflows/crypto-classroom/>)

## 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`