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

MEGASCON (hash-18)

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

Follow-up source: Megascon team's revision notice

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

12a06f59d0c531c20cf4efad19195ba328c2aa92e8ef76b344f7084b98cc88a913f71388bb289e33b76accc9966d7cf4

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

907761161784fcce7082995b14ee6036

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 15-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.

The frozen Round 1 archive remains the target of this finding.

Proposed fixes

The Megascon team's revision notice proposes a distinct four-bit initialization domain for every digest and XOF profile and reports regenerated specifications, implementations, and 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).

Build the candidate and the reproducer, then run:

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

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

hash-18-2: The AVX-512 listing defines a noninjective S-box and practical collisions

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

Listing 3 uses ternary-logic immediates b4 and 1e with the wrong operand truth-table order. Its induced S-box has only 175 distinct outputs; in particular, S_bad(23) = S_bad(24) = 1b. A local collision can therefore be injected through the rate and makes the complete states equal after the second block's first substitution layer.

For MEGASCON-512, take two 256-byte messages initialized to zero, set M[192] = 04, and set N[128] = N[160] = 04. Under Listing 3, both hash to:

2ed13b513054b271a9640e8ccc139d5a363cc69eee4158ec7453b6e39b3549a15a87b8695340271fdcb02903cfe42b79ea8227f074e05599299a318581faf368

This is a specification-listing failure, not an attack on the archived implementations: the optimized code uses the corrected immediates a6 and 56, and the reference code implements the bijective mathematical S-box.

The Megascon team confirms that Listing 3 was a transcription error. The submitted source already uses a6 and 56.

Proposed fixes

The Megascon team's correction proposes replacing Listing 3's b4/1e immediates by a6/56. 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).

The local checker verifies the erroneous truth tables, the displayed collision inside the S-box, and bijectivity after correction:

python3 hash-18/validate_listing3.py

The complete-message collision above was independently evaluated in Python and scalar C by the reporters; no native AVX-512 execution is required or claimed.