Home / The record / EdDSA, the new clause
6.13.4.2
The pre-signature is one scalar multiple
The signing entity computes the point that is the randomizer times the base point, and the clause notes that reducing the randomizer modulo the order of the base point first is an equivalent and more efficient route. The result is the value that becomes the witness once encoded.
- What it asks
- Compute the pre-signature with the base point of the set in use, and record whether the implementation reduces the scalar first. Both routes are permitted, so the record should say which one the code takes, and the test vectors should agree with it.
- What the amendment does
- Inserts 6.13.4.2. So this is new text rather than a change to wording.
- Who it binds
- The signing implementation owner.
- Evidence an auditor samples
- The code that computes the pre-signature, naming the base point (source repository)
- The test vector that matches the route the code takes (test suite)
- The performance note, if the reduction is used (design note)
- The test you can run
- Run the published example and compare the pre-signature. A mismatch usually means the wrong base point or an unreduced scalar used in the wrong place.
- Common failures
- The base point is taken from a library default rather than the clause table.
- The reduction is added in one code path and not in the verification path.
- How to close it
- The pre-signature is an intermediate value, so nobody looks at it until an interoperation test fails. Compare it against a worked example during development, not during an incident. Start with the code that computes the pre-signature, naming the base point 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.4.2 is the only place a reader can see it.