Skip to content

[go-CAN-11] THREAT_MODEL overstates HMAC parity with rust-CAN, glossing over a safety-classification and feature-gating divergence #83

Description

@SoundMatt

Location: THREAT_MODEL.md:74-82; safety/auth.go:43 vs. rust-CAN/src/safety/hmac_auth.rs:18

Finding: THREAT_MODEL.md states that go-CAN's safety.HmacSha256Auth "mirrors" rust-CAN's safety::hmac_auth and is "behaviourally equivalent... for the authentication surface," citing the same primitive, tag size, and constant-time comparison. The cryptographic claims check out (both are HMAC-SHA256, 32-byte tag, constant-time compare). But two things the equivalence claim glosses over: (1) go-CAN's doc comment cites "IEC 62443 SL-2 and ISO/SAE 21434" while rust-CAN's cites the same standards plus an explicit "CAL-3" cybersecurity assurance level — the two docs aren't actually asserting the same compliance claim; and (2) rust-CAN gates its HMAC implementation behind an opt-in hmac-auth Cargo feature (confirmed in its Cargo.toml), while go-CAN always compiles the equivalent code in unconditionally. So the two implementations differ in both stated safety classification and default availability, which "behaviourally equivalent" and "mirrors" don't really capture.

Recommendation: Either align the safety-classification wording between the two docs, or soften the equivalence claim to explicitly note the CAL-3 wording difference and rust-CAN's feature-flag gating.

Filed from the 2026-07-29 ecosystem audit register; independently re-verified against current HEAD before filing.

Metadata

Metadata

Assignees

No one assigned

    Labels

    docsDocumentation improvementssev:lowLow severity

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions