Recognised protocol, no home-made crypto

Verifies

Requires an AI engine: Message encryption uses a recognised protocol and vetted primitives; no custom cipher, custom key schedule, ECB mode, obsolete cipher, static IV or non-cryptographic randomness.

Inputs

Non-test code files of the checkout (JavaScript, TypeScript, Python, PHP). Messaging files are located by path or content; cryptographic files by encryption, key-derivation and protocol vocabulary. The cryptographic files (at most 24, those without a recognised library 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). Speed pass (1.0.8): each file goes to the model as the EXCERPT of the lines relevant to the requirement (encryption, decryption, ciphers and modes, key derivation, nonces, randomness and the protocol library), 12 lines around each of them (the whole file when that is most of it), omitted spans marked; every cryptographic file has such lines by construction, so none is dropped; at most 48 files, most relevant first; parts are cut by path with content-defined boundaries and a context that lists no files, so an unchanged file lands in an unchanged part the engine may answer from its verdict cache; up to the engine's concurrent-call limit, parts go in parallel and are aggregated in part order.

Decision rule

Not applicable when the checkout has no messaging feature. FAIL (HIGH) when the messaging feature has no cryptographic code at all, when no recognised protocol or vetted library is referenced, or when a cryptographic file uses ECB, createCipher, DES/3DES/RC4/Blowfish, MD5/SHA-1 as key derivation, Math.random/random/rand/mt_rand for a key, nonce or IV, a hand-written XOR cipher, a custom cipher name, or a static or zero IV. NAMING a home-made construction is not implementing one (1.0.5): the custom-cipher rule matches NAMES (caesar, rot13, vigenere, xorCipher, myEncrypt, homemade, homebrew), and a name is reported only where it is CODE — a bare identifier that is declared, called or referenced, a quoted name in an ALGORITHM POSITION (the argument of a cipher/encrypt/decrypt call, or the value of an algorithm, cipher, mode or transformation field) or the module of an import or require. A name inside a hyphenated slug, which is not an identifier in any language this check reads, and a quoted name anywhere else — an entry of a catalogue or a security policy, the id of a rule or a check, a key of a map, the prose of a message — is the construction being MENTIONED, is not reported, and the trace names the file, the line and why. The other rules are unchanged. The model must establish with confidence of at least 0.8 that the construction follows the protocol (AEAD, fresh nonces, HKDF-derived keys): an unsatisfied or undecided assessment is a FAIL, a HIGH finding is a FAIL, MEDIUM blocks only inside Extended suites, 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.9: the SCOPE rule of 1.0.7 is repeated a second time with named out-of-scope examples (service/session authentication tokens — a chat attachment stays IN scope) and a service-token file is now excluded at the deterministic layer, the same defence in depth already given to KMS/webhook code; a rule against reporting a freshly-generated key or IV as "reused" without caching evidence was added too (1.0.8: SPEED PASS: each file goes to the model as the EXCERPT around the lines the deterministic part marked relevant to THIS requirement (the choice of primitive and mode, key derivation, nonces and randomness, the protocol library, the home-made constructions), 12 lines on each side (the whole file when that is most of it); the omitted spans are marked in place and a finding on a line that was not sent is dropped. A cryptographic file with none of them falls back to its generic crypto lines, so none is dropped. Up to 48 files, most relevant first, instead of 24 whole ones. STABLE PARTS: the files are packed by path with content-defined part boundaries (decided by the path, never by the content) and the repository context lists no files, so an unchanged file lands in a byte-identical part the engine may answer from its verdict cache (per organisation, declared in the trace and in the attestation). The parts are sent in parallel up to what the engine admits (ctx.ai.maxConcurrentCalls) and aggregated in part order, so the verdict never depends on which answer arrives first. The assessment reason is ONE sentence of at most 30 words (the platform GPU spends 46 ms per output token and the reason was most of every answer). Requirement, categories and decision rule unchanged. (1.0.7: the rubric did not bound the judgement to the encryption of MESSAGES: a helper encrypting stored secrets at rest (signing keys, credentials, tokens) with AES-256-GCM from node:crypto was assessed as if it were the messaging protocol. The assessment is now scoped to message content, message keys and their sessions, and AEAD from node:crypto with random nonces and HKDF keys is named as a vetted construction. (1.0.6: a cryptographic file used to be judged by this check as soon as the checkout had a messaging feature ANYWHERE, even when the crypto file itself has nothing to do with messaging — an unrelated internal signing or envelope-encryption service that shares the repository with a real chat feature was assessed as if its primitives were the messaging feature's own encryption. A cryptographic file with STRONG evidence of being operational infrastructure (envelope encryption of secrets at rest under a KMS-managed key, or signing/verifying a machine-to-machine handshake or a third-party webhook) is no longer judged unless it also addresses a person (recipient, sender, participant) — general vocabulary any codebase uses for this, never a name of one particular repository or file. (1.0.5: NAMING a home-made construction is not implementing one. The custom-cipher rule matches NAMES (caesar, rot13, vigenere, xorCipher, myEncrypt, homemade, homebrew) and a name is reported only where it is CODE: a bare identifier that is declared, called or referenced, a quoted name in an ALGORITHM POSITION (the argument of a cipher/encrypt/decrypt call, or the value of an algorithm, cipher, mode or transformation field) or the module of an import or require. A name inside a hyphenated slug — never an identifier in JavaScript, TypeScript, Python or PHP — and a quoted name anywhere else (an entry of a catalogue or a security policy, the id of a rule or a check, a key of a map, the prose of a message) is the construction being MENTIONED, is not reported, and the trace names the file, the line and why: a checkout that DESCRIBES the defect does not have it. The other seven rules (ECB, createCipher, obsolete ciphers, weak randomness, hand-written XOR, static IV) and the model part are unchanged. (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.