Home / The record / Annexes changed
Annex F
Worked examples for both parameter sets
Annex F gains worked examples for the two EdDSA sets, Ed25519 and Ed448, covering key generation, signing and verification. The examples are the cheapest way to prove an implementation is on the specified path, and they are the evidence a reviewer will ask for.
- What it asks
- Run the worked examples in continuous integration, for both sets, and keep the output. Where an example fails, treat it as a defect in the implementation before treating it as a defect in the example, and record which one it was.
- What the amendment does
- Adds EdDSA worked examples to Annex F. So the annex keeps its base text and gains this material, which a copy of the base annex will not have.
- Who it binds
- The test owner and the release manager.
- Evidence an auditor samples
- The test that runs each worked example, with the expected values (test suite)
- The last run output, dated, for both sets (release record)
- The defect record for any example that failed and why (issue tracker)
- The test you can run
- Run the examples against a fresh build. A pass on one set and a skip on the other is a finding, not a partial pass.
- Common failures
- One set is tested and the other is assumed to work.
- The example is run once by hand and never in the pipeline.
- How to close it
- Worked examples are the highest value test per line of code in a cryptography change. Put them in the pipeline for both sets, and make the release record quote the run rather than the intention. Start with the test that runs each worked example, with the expected values and let the row close when it exists with a date and a named holder.
- Where it sits against the base standard
- The annex exists in the base standard and the amendment extends it. A copy of the base annex is not the current annex, so the citation must name the amendment as well as the edition.