Overview

This r/crypto thread accompanies the “Ed25519 Deep Dive Addendum,” a follow-up blog post by Cendyne that responds to feedback on an earlier explainer about the Ed25519 signature scheme. The discussion is a technically dense exchange among practitioners about why real-world Ed25519 implementations disagree on which signatures they accept, and about how the security expectations placed on the primitive have shifted over time. Ed25519 is the EdDSA instantiation over the Curve25519-based Edwards curve, designed by Bernstein, Duif, Lange, Schwabe, and Yang, and later standardized in RFC 8032. The thread emphasizes the gap between clean cryptographic theory and the messy engineering reality of maintaining interoperable, backward-compatible libraries.

Key points

• Ed25519 libraries apply inconsistent validation criteria, so a signature accepted by one implementation can be rejected by another. This mirrors the systematic findings of the “Taming the many EdDSAs” analysis, which cataloged how popular libraries differ on edge cases.
• A central divergence is cofactored versus cofactorless verification: whether the verification equation multiplies through by the curve cofactor (8). Cofactored checks and single versus batch verification can accept or reject different “shady” signatures involving small-order or mixed-order points.
• Strong unforgeability (SUF-CMA) requires rejecting non-canonical scalars, notably enforcing that the signature scalar S is reduced modulo the group order L (S < L), which blocks signature malleability. Not all implementations enforce this.
• Non-canonical point encodings and small-order public keys are additional sources of cross-library disagreement.
• A recurring theme defends the original designers: expectations like strong unforgeability guarantees and exhaustive test-vector coverage largely emerged in the community after Ed25519 was first published, so judging the primitive by later standards is anachronistic.
• Practical constraints (preserving compatibility, avoiding breaking deployed systems, minimizing risk) often outweigh the desire to retrofit stricter, fully standardized validation behavior.

Relevance to Truestamp

Truestamp uses Ed25519 signatures to sign proof artifacts, so implementation-level details like canonical scalar checks (S < L), cofactored verification, and cross-library acceptance criteria bear directly on whether a signature verifies consistently across the tools that consume its proofs.

Citations

1. Ed25519 Deep Dive Addendum (r/crypto). r/crypto discussion thread (2022) for Cendyne’s “Ed25519 Deep Dive Addendum” blog post; related analysis in Brendel, Cremers, Jackson, and Zhao, “Taming the many EdDSAs” (2020).