Security › hash-20 · Constant-time review · Performance: x86_1 · arm_1

MOZI (hash-20)

hash-20-1: For short messages, the 384-bit digest is a prefix of the 512-bit digest

Follow-up source: Iphe Algorithm Group's 2026-09-23 forum note

For the 24-bit message hex 616263 (abc), MOZI-384 returns:

f3aa50e4542947c662f18092b6b4079e489192491a8f13b49ebd108352e49d1da81e938795a675a409083fce63f2eb1f

MOZI-512 returns that exact 48-byte value followed by:

69444aab68ec23d14f909ef4ce1b9b63

For every message shorter than 1024 bits, both variants initialize the same zero state, inject identical padded bytes at the same offset, and apply the same 20-round permutation. The digest length or variant identifier is never absorbed; only the amount returned to the caller differs.

The two functions therefore lack cross-variant domain separation and cannot be treated as independent hashes. No explicit specification claim of cross-profile independence was located, so this is reported as a confirmed composition defect rather than a collision-resistance claim violation.

The same missing domain separation affects the XOF profiles. On the audited short messages, the 384- and 512-profile 256-bit XOF outputs are equal, while shorter outputs are prefixes of the longer XOF streams. This follows from the normative zero initialization, common padding and permutation, and MSB_l output rule; it is not only a wrapper artifact.

Follow-up analysis: the Iphe Algorithm Group's cross-rate note, posted by 崔灏睿 on 2026-09-23 independently identifies this one-block MOZI-384/MOZI-512 prefix relation.

The archived Round 1 ZIP above remains the subject of this report.

Proposed fixes

The Mozi team's 2026-09-28 response proposes a distinct four-bit initialization domain for every variant. This section records the proposal without evaluating it.

Reproducing

Commands below run in a checkout of the ngcc-harness repository with the candidate built (see its README).

Build the candidate and the reproducer, then run:

make -C api harness && make -C tools && make -C hash-20
tools/ngcc_attack hash-prefix hash-20/lib/libMOZI-384.so hash-20/lib/libMOZI-512.so

tools/reproduce.sh runs this together with the other supported runtime witnesses and their controls. See tools/README.md.

hash-20-2: The specified final marker creates cross-rate relations absent from the implementation

Original source: CryptHashForum report Follow-up source: Mozi team's correction

Algorithm 2 places the final marker at the same absolute state bit for every rate. This permits a three-block suffix under one rate to reproduce the same permutation input as a related suffix under another rate. The submitters report 16/16 cross-rate witnesses in an independent model of the specified construction. This is a relation between different MOZI profiles, not a same-profile collision.

The reference code instead places the marker at the first capacity bit, which is bit 1216 for MOZI-768 and bit 960 for MOZI-1024 rather than the specification's common bit 2047. That rate-dependent placement blocks the reported construction, but makes the code deterministically incompatible with Algorithm 2. The public report did not include its 16 witness messages, so the local check confirms the exact marker discrepancy rather than claiming an end-to-end collision reproduction.

The archived submission remains the target of this finding.

Proposed fixes

The Mozi team's 2026-09-28 response proposes making the reference code match Algorithm 2, adding per-variant initialization domains, and regenerating the KATs. This section records the proposal without evaluating it.

Reproducing

Commands below run in a checkout of the ngcc-harness repository with the candidate built (see its README).

make -C hash-20 reproduce-forum