BIP-375's DLEQ challenge was not reduced modulo the group order
Victoria Shinder2 min readPull request #2304 from Bruce039 has been merged into the BIPs repository, touching a single file - bip-0375/deps/dleq.py - with three additions and one deletion. The substance of it is one operator. In dleq_challenge, the value built from the hashed inputs and converted from bytes is now returned as ... ) % GE.ORDER rather than as the raw integer, and two lines are added inside dleq_verify_proof.
What it means
A DLEQ proof - discrete logarithm equality - is how a party demonstrates that two public points share the same secret scalar without revealing it, and BIP-375 carries one in its reference dependencies. The challenge in such a proof is a scalar, which means it must live in the range of the group order; deriving it by hashing and then treating the result as an integer produces a value that is usually in range and sometimes is not. Reducing modulo GE.ORDER makes that explicit rather than accidental.
The reason a one-operator diff in a reference implementation is worth noting is interoperability. Reference code in a BIP is what independent implementers read to decide what their own code must do, and an unreduced challenge is exactly the sort of detail that two implementations will handle differently without either author noticing - because the disagreement only appears for inputs that hash above the order, which is rare enough to pass every test anyone wrote by hand. Whichever side reduces produces a different challenge, and the proof fails to verify across implementations for reasons that look like data corruption.
The general shape is familiar from outside cryptography: a value with a stated domain, an operation that does not enforce the domain, and a test corpus that never happens to leave it. The fix is to make the constraint executable rather than documentary. Worth pulling the two added lines in dleq_verify_proof if you are implementing BIP-375 against this reference, since verification changing at the same time as generation is how a version skew becomes a compatibility bug.