Ed25519签名方案Donna与Supercop实现单向兼容性问题问询

Great catch—this is a perfect example of how tiny, easy-to-miss deviations from the original Ed25519 spec can create one-way compatibility issues between implementations. Let’s break down the most probable causes:

• Strict S-Value Range Checks in Supercop
  The original Ed25519 specification mandates that the S component of a signature must be within [0, L), where L is the curve’s order (2^252 + 27742317777372353535851937790883648493). Some implementations (like Donna) might skip reducing S modulo L during signature generation, resulting in an S value that’s larger than L.

  Supercop’s implementation (built directly from Daniel Bernstein’s original NaCl codebase) enforces this range check rigorously—if S is out of bounds, it rejects the signature immediately. Donna’s verifier, though, is more forgiving: it computes the necessary point multiplication regardless of S’s size, since mathematically S*B is identical to (S mod L)*B on the elliptic curve. That’s why Supercop’s valid signatures pass Donna’s check, but Donna’s signatures fail Supercop’s strict validation.

• Unintended Use of Ed25519 Variants
  Ed25519 has several standardized variants: plain Ed25519, Ed25519ph (for prehashed messages), and Ed25519ctx (which includes a context string). Donna might default to one of these variants (even with an empty context) while Supercop strictly adheres to plain Ed25519.

  If Donna adds a context prefix to the hash input when generating signatures, Supercop’s verifier (which doesn’t expect this extra data) will compute a mismatched challenge hash, leading to verification failure. On the flip side, when verifying Supercop’s plain signatures, Donna’s verifier likely ignores context parameters (or defaults to an empty context), so the hash matches and verification succeeds.

• Hash Input Order/Truncation Discrepancies
  The original spec defines an exact order for concatenating data during hash calculations (e.g., H(R || A || m) for verification, where R is the signature’s first 32 bytes, A is the public key, and m is the message). While uncommon, some implementations accidentally swap these components or truncate data incorrectly.

  If Donna uses a different order (like H(A || R || m)) when generating signatures, Supercop’s verifier will compute the wrong challenge value and reject the signature. But when verifying Supercop’s signatures, Donna uses the correct order, so the check passes.

Quick Fixes for Bidirectional Compatibility #

1. Disable Ed25519 Variants in Donna: Ensure Donna is configured to use plain Ed25519 (turn off any prehash or context options if they’re enabled by default).
2. Enforce S-Value Modulo Reduction: Force Donna to reduce S modulo L during signature generation—check the implementation’s docs for a flag or setting to enable strict spec compliance.
3. Align Hash Handling: Double-check that both implementations follow the exact hash input order and truncation rules laid out in the original Ed25519 spec.

内容的提问来源于stack exchange，提问作者Juraj Muravský