Home / The record / EdDSA, the new clause
6.13.5.4
The assignment is recomputed, not trusted
The verifier recomputes the assignment from the same fields the signer used, with the verification key in place of the signing key, and reads the digest the same way. Nothing in the signature carries the assignment, so it cannot be trusted from the message; it has to be derived again.
- What it asks
- Recompute the assignment with the same field order, the same domain octet and the same length and endianness as the signer, and reduce it modulo the order of the base point. Record the field order in the design note and test it against a second implementation.
- What the amendment does
- Inserts 6.13.5.4. So this is new text rather than a change to wording.
- Who it binds
- The verifier owner and the test owner.
- Evidence an auditor samples
- The recomputation code, with the field order named (source repository)
- The cross-implementation test for the assignment (test suite)
- The endianness test (test suite)
- The test you can run
- Change the order of two fields in the recomputation and verify. The signature must fail. If it still verifies, the fields are not both being hashed.
- Common failures
- The verifier reads a stored assignment instead of recomputing it.
- The digest is read big endian while the signer read it little endian.
- How to close it
- The assignment is the one value both sides must derive identically. Put the formula in the design note, test it against a second implementation, and treat a change to it as a breaking change for every stored signature. Start with the recomputation code, with the field order named and let the row close when it exists with a date and a named holder.
- Where it sits against the base standard
- The base standard does not carry this text. The amendment adds it, so an estate working from the 2018 edition alone will not find it. The citation has to name the amendment, and the record for 6.13.5.4 is the only place a reader can see it.