ECAI Encoding Checks and Proof Boundaries
What canonicalisation, domain separation, hash-to-curve, signatures and retrieval checks establish—and what they do not.
Define the property before calling it a proof
The earlier educational material used “proof” for several different checks. A reproducible encoding, a valid signature and a correct answer are different properties. An experiment should state its input, algorithm, trusted reference and expected outcome.
| Check | Useful conclusion | Limit |
|---|---|---|
| Canonicalisation | Defined formatting variants produce identical canonical bytes | Whitespace handling does not prove semantic equivalence |
| Domain separation | Distinct, unambiguously encoded contexts feed distinct hash inputs | Hash collisions are not mathematically impossible |
| Hash-to-curve | The chosen suite maps input bytes to a valid group element | It does not recover the original arbitrary-length input |
| Signature verification | A payload verifies under the supplied public key | It does not establish who should be trusted or whether the claim is true |
| Record lookup | A retained record matches the requested identity | Lookup is not a zero-knowledge proof protocol |
| Relation composition | A result follows from stated rules over encoded facts | The rules and input facts may be incomplete or wrong |
Canonicalisation is a schema decision
Collapsing whitespace can make two text encodings equal. It does not prove that different sentences mean the same thing. Preserve the original record, version the canonicalisation rules and test cases where punctuation, case, units or context change meaning.
Domain separation also needs unambiguous serialisation. Concatenating arbitrary fields with a delimiter is insufficient when that delimiter can occur in the fields; use the selected format's explicit boundaries and version tag.
Use a specified curve construction
RFC 9380 describes hash-to-curve suites and their test vectors. Follow a suite suitable for the protocol, including its domain separation and group requirements. Point serialisation/deserialisation is a different operation from hashing arbitrary bytes to a curve.
Earlier snippets that prefixed a digest with 0x02 or used an unbounded
try-and-increment loop are not production cryptographic implementations.
Educational scalar or toy-curve mappings must not be presented as conforming
hash-to-curve suites without demonstrating the required properties.
Retain the record to retrieve it
A content hash is a compact identifier, not a reversible encoding of all text. Exact retrieval requires retained bytes and a lookup path. To verify a record, retrieve it, recompute the chosen identity and compare it with a trusted reference. Then evaluate whether the record supports the question being asked.
A signature can authenticate an inaccurate record. A Merkle inclusion proof can bind it to a root that the reader has no reason to trust. State the trust anchor and the claim being checked.
Security claims need an algorithm and threat model
Elliptic-curve operations alone do not establish post-quantum security. Research on quantum elliptic-curve discrete logarithms examines attacks on the mathematical problem used by conventional ECC. NIST's PQC guidance also treats hybrid constructions as requiring analysis for their application.
The private-index guide records a separate cryptographic backend boundary; its presence in source is not a validation result for the installed backend.
Evaluate the implemented paths
Use the relation reference, search and evidence reference and private retrieval reference. Record actual test results against a revision and preserve their scope in the capability matrix. This page adds no new cryptographic proof, runtime result or benchmark score.