Summary
Informational, and it is the good outcome: CIRISEdge is already DRY here. Every production Ed25519 verification goes through ciris_crypto::Ed25519Verifier — no direct ed25519-dalek dep anywhere in the repo:
| file:line |
path |
src/identity.rs:337 |
identity |
src/transport/attestation.rs:577 |
transport attestation |
src/transport/realtime_av_alm/capacity.rs:518 |
§19.4 ALM capacity |
Because of that, adopting CIRISVerify v17.0.0 changes edge's acceptance rule for free — and you should know it's happening rather than discover it.
What changes
v17.0.0 makes ciris_crypto::Ed25519Verifier's ClassicalVerifier::verify strict (rejects small-order / torsion-component A and R). It was permissive before, and permissive accepts a universal forgery: with the identity point as the public key, the single 64-byte string (R = identity, s = 0) verifies against any message, with no private key in existence. The three sites above all used the permissive rule, so they all tighten on adopt.
Cut MAJOR although nothing fails to compile — a runtime acceptance rule changed fleet-wide, and after the #257/#274 lessons the version number should say so rather than let it arrive on a cargo update.
Why this should be a non-event for you
No honest signer is affected: an honest key is not small-order and an honest signature's R carries no torsion component. Verify's full 1529-test suite is green under strict, including the baked humanity_accord_genesis quorum — the constitutional root produced on physical YubiKeys.
If you hold a stored corpus of Ed25519 signatures from an exotic or historical signer, re-verify it once on adopt. A signature that stops verifying was never something an honest signer produced, but better to learn that deliberately than at a gate.
Also available if useful
ciris_crypto::Ed25519Verifier::verify_permissive keeps the old rule reachable under a name that says what it is — for reproducing another implementation's acceptance set deliberately, never for deciding anything. If any edge path needs to explain why a peer accepted something edge refuses, that's the tool.
Filed from a crypto-DRY pass across edge/server/persist/agent off CIRISVerify#207 item 1. Companion issues: CIRISAgent#1201, CIRISServer#654, and one on CIRISPersist.
Summary
Informational, and it is the good outcome: CIRISEdge is already DRY here. Every production Ed25519 verification goes through
ciris_crypto::Ed25519Verifier— no directed25519-dalekdep anywhere in the repo:src/identity.rs:337src/transport/attestation.rs:577src/transport/realtime_av_alm/capacity.rs:518Because of that, adopting CIRISVerify v17.0.0 changes edge's acceptance rule for free — and you should know it's happening rather than discover it.
What changes
v17.0.0 makes
ciris_crypto::Ed25519Verifier'sClassicalVerifier::verifystrict (rejects small-order / torsion-componentAandR). It was permissive before, and permissive accepts a universal forgery: with the identity point as the public key, the single 64-byte string(R = identity, s = 0)verifies against any message, with no private key in existence. The three sites above all used the permissive rule, so they all tighten on adopt.Cut MAJOR although nothing fails to compile — a runtime acceptance rule changed fleet-wide, and after the #257/#274 lessons the version number should say so rather than let it arrive on a
cargo update.Why this should be a non-event for you
No honest signer is affected: an honest key is not small-order and an honest signature's
Rcarries no torsion component. Verify's full 1529-test suite is green under strict, including the bakedhumanity_accord_genesisquorum — the constitutional root produced on physical YubiKeys.If you hold a stored corpus of Ed25519 signatures from an exotic or historical signer, re-verify it once on adopt. A signature that stops verifying was never something an honest signer produced, but better to learn that deliberately than at a gate.
Also available if useful
ciris_crypto::Ed25519Verifier::verify_permissivekeeps the old rule reachable under a name that says what it is — for reproducing another implementation's acceptance set deliberately, never for deciding anything. If any edge path needs to explain why a peer accepted something edge refuses, that's the tool.Filed from a crypto-DRY pass across edge/server/persist/agent off CIRISVerify#207 item 1. Companion issues: CIRISAgent#1201, CIRISServer#654, and one on CIRISPersist.