VER-001: Non-standard 0x29 detached Falcon signatures are accepted

[gnosed]

Description

The verifier accepts both 0x29 and 0x39 as headers for the same detached signature layout:

header || nonce[40] || compressed(s₂)

After checking that the high nibble is either 0x2X or 0x3X, the verifier always extracts bytes 1–40 as the nonce and invokes the compressed polynomial decoder. The selected header family therefore has no effect on framing or decoding.

This conflates two distinct formats defined by Falcon:

• 0x39 identifies a Falcon-512 compressed signature containing the nonce. Both natural-length and 666-byte padded signatures use this header.
• 0x59 identifies the alternate fixed-width/constant-time encoding and requires a different decoder.
• 0x29 is used only for the nonce-less signature tail inside the NIST crypto_sign signed-message envelope.

Consequently, the local representation 0x29 || nonce || compressed(s₂) is a non-standard hybrid format.

The comments claiming that signers disagree about the meanings of these nibbles are inaccurate. The Falcon specification, reference C implementation, PQClean, and the Python signer agree on the relevant conventions:

• Detached compressed and padded Falcon-512 signatures use 0x39.
• The CT/fixed-width representation uses 0x59.
• 0x29 belongs to the nonce-less tail of the NIST signed-message envelope.

The KAT tests currently create the non-standard hybrid by extracting the nonce from the NIST envelope while preserving its 0x29 nonce-less header. A correct conversion to detached form would replace 0x29 with 0x39.

Impact

An attacker can change the first byte of a valid 0x39 signature to 0x29 without invalidating it. This produces multiple accepted byte encodings for the same signature and message.

This does not appear to enable a signature over a new message or public key. However, it has the following consequences:

• The verifier accepts signatures that do not conform to either defined Falcon framing.
• Signature bytes are malleable, which can affect systems that hash, identify, deduplicate, cache, or route signatures using their serialized representation.
• The permissive behavior can cause interoperability differences with strict Falcon implementations, whose detached verifiers reject 0x29.
• It creates ambiguity for future format dispatch, particularly if support for the 0x59 fixed-width encoding is added.
• Documentation incorrectly treats the behavior as necessary for signer interoperability.

Recommendation

Require 0x39 for every compressed detached Falcon-512 signature:

if signature[0] != 0x39 {
    return false;
}

Continue determining natural versus padded compressed form from decoder consumption and length:

• Accept exact consumption for a natural-length compressed signature.
• Accept trailing zeros only when the total signature length is exactly 666 bytes.
• Do not use 0x29 to identify padded signatures; padded signatures also use 0x39.

Developers Response

The developers have been notified of the issue, but not yet provided a response.

[HusseinAdeiza]

Confirmed the core of VER-001 against main independently, and the mechanism is exactly as you describe. The binding is dead code in the strict sense: fmt is bound at verify.rs:117 and never read again anywhere in the file, so the accepted family has zero effect on framing or decoding.

let fmt = sig_header & 0xF0;
if fmt != 0x20 && fmt != 0x30 {
    return false;
}

followed unconditionally by the fixed &signature[1..41] nonce extraction at Step 4 and the compressed decoder at Step 5. So a 0x39 body re-headered to 0x29 decodes to the same s_2, and the later canonicity check on the body is what actually decides acceptance. That is the malleability, and it follows directly from the family being advisory rather than load-bearing.

I also checked the test at verify.rs:431 and it is consistent with your reading rather than contradictory to it. test_message_too_long_rejected sets sig[0] = 0x29 on a zeroed buffer only to get past the header check, and test_ct_format_rejected_by_size_gate covers 0x59. Neither pins the 0x29/0x39 equivalence, so nothing currently fails if you make the family strict, which means the KAT harness you are updating is the only place that will need to agree with the new behaviour.

One thing I would check while you are in here, since it is adjacent to the framing change and cheap to get wrong. test_ct_format_rejected_by_size_gate documents that 0x5X is rejected by the size gate because 809 > FALCON_SIG_MAX_SIZE = 666. If the framing fix tightens the family check to 0x39 only, that test still passes but stops testing what its name claims, because the family gate would now be rejecting it rather than the size gate. Worth either renaming it or leaving a comment saying which gate is load-bearing after the change, otherwise the next person to relax the size limit inherits a test that no longer proves what it says.

I am not asking for anything to be added to the PR. I read the code, confirmed the finding, and this is a heads-up on a test that your change will quietly make a misnomer.

For the record on my side: I looked for an unclaimed issue to pick up here and there is nothing in this repo. The only open issue in the org is pqchain#4, which is assigned, and these five audit PRs are gnosed remediating Veridise findings on their own audit package. So this is a comment, not a competing contribution.