Multi-device key management

Verifies

Requires an AI engine: In an end-to-end messaging feature with several devices per user, every device holds its own keys, linking exchanges public keys or device-side encrypted material only, and revoking a device stops it from decrypting later messages.

Inputs

Non-test code files of the checkout (JavaScript, TypeScript, Python, PHP). The device model is detected by device identifiers, registries and link or revoke code next to key or session vocabulary. The device-management files (at most 24, link/revoke files first) are sent together in one assessment call to the chosen engine through the platform ai service; at most 160000 estimated tokens. Paths listed in excludes (test, spec and tmp files, __tests__, __mocks__, fixtures, test, tests and audit-scripts folders) are never analysed. Every model call (rubric, repository context and files) stays under 120000 characters; a candidate set that does not fit is sent in parts, each part bounded by what the chosen engine serves in one call (the engine publishes that budget; a call is never filled up to the transport cap).

Decision rule

Not applicable without a messaging feature, without an end-to-end protocol, or without a device model (single-device design). FAIL (HIGH) when a private key is exported and sent or stored without device-side encryption, or when a backup, sync or transfer uploads private material without device-side encryption. A device revocation path without a session invalidation, rotation or exclusion signal in its file is MEDIUM (blocks in this Extended suite). The model must establish with confidence of at least 0.8 the three requirements: an unsatisfied or undecided assessment is a FAIL, a HIGH finding is a FAIL, an unparseable answer is a FAIL. PASS only with a satisfied assessment and nothing blocking. When the candidate set goes in parts, a HIGH finding in any part is a FAIL and the assessment is unsatisfied when any part says so, satisfied only when a part establishes it and none denies it. A messaging feature exists only with a message or conversation model, a chat transport, a messaging protocol library, a chat UI or end-to-end keys in a messaging folder somewhere in the checkout: messaging vocabulary alone is not-applicable with the reason (1.0.2). Without an AI engine the check is not executed (requires an AI engine).

Type

ai-assisted · engine chosen by the organisation · medium

1.0.4: `assess` mode cuts the candidate set to what the chosen ENGINE serves in ONE call (`ctx.ai.maxInputChars`, published by the engine per its catalogue budget; `ENGINE_CALL_MAX_CHARS` = 32 000 when an older sandbox does not publish it), instead of filling the call up to the TRANSPORT cap of the proxy (`spec.promptMaxChars`, unchanged at 120 000). On a 1 319-file checkout the old packing produced single prompts of 17 672 / 26 709 / 29 351 tokens and the platform GPU answered "CUDA out of memory": the check ended in `error`. Every call of the same run under ~24 000 characters was answered normally. The part aggregation of 1.0.1 is unchanged: a HIGH in any part is a FAIL, an unsatisfied part is a FAIL, undecided never passes. (1.0.3: requires an AI engine (spec.requiresEngine: true): the check needs judgement and is executed only when the organisation provides an engine; the core catalogue runs without one. (1.0.2: applies only to a real messaging feature: a message or conversation model, a chat transport (socket, channel or pub/sub events of a conversation), a messaging protocol library (Signal, MLS, Olm/Megolm, XMPP) or a chat UI; messaging vocabulary alone (an error message pushed to a queue, a notification channel, a case signal route) is not-applicable with the reason; never analyses temporary files (*.tmp.*; spec.excludes follows AUDITOR_ANALYSIS_EXCLUDES). (1.0.1: never analyses test, spec, fixture and mock paths nor the auditor's own scripts (spec.excludes = AUDITOR_ANALYSIS_EXCLUDES); a fixture-looking secret (sk_test_, example, dummy) in real code is LOW, informative; every model call stays under the engine prompt cap (spec.promptMaxChars = AUDITOR_AI_PROMPT_MAX_CHARS): assess mode sends the candidate set in parts and aggregates the verdicts (a HIGH in any part is a FAIL, an unsatisfied part is a FAIL).)))

The full script is disclosed on request in a read-only viewer (never published on GitHub); the attestation binds to this exact hash.