Vulnerability report classification

This document defines how NGCC findings receive Severity, Status, Layer, and Discovery labels. These labels answer different questions and must be assigned independently:

• Severity describes the demonstrated or bounded security impact.
• Status describes the strength of the evidence for the stated finding.
• Layer identifies where the vulnerable behavior enters.
• Discovery describes the effort needed to identify and substantiate the finding, not its impact or attack cost.
• Remediation burden describes the cost of removing the behavior. It is normally separate context. For side-channel findings, however, the absence of a portable and reasonably efficient constant-time realization can be evidence that the problem belongs to the design and performance profile.

A finding can therefore be Critical but easy to fix, or Low but expensive to fix. An expensive constant-time implementation is not automatically a design flaw, but it becomes design evidence when the construction's claimed software performance relies on the leaky operation and no portable competitive constant-time path is supplied or known.

Here supplied means the submitters provide the constant-time code, and known means a well-known security-engineering technique exists that the report itself can describe (for example masked arithmetic, bitslicing, in-register shuffles, AES instructions, Beneš networks, or a published constant-time decoder or solver). The same meaning applies to hash functions.

Proposed fixes

When a report records a proposed change, whether communicated publicly or privately, it places that material in a Proposed fixes subsection and attributes the source. An attributed attack or concern about a proposed change may also be noted there, clearly scoped to the proposal. Recording it does not establish that a revision is correct, sufficient, complete, compatible, or secure, and does not alter the archived submission's classification. A revised candidate requires separate evaluation. Reports may state that one attack route is independent of another mechanism, but must not turn that observation alone into a verdict on a proposed fix.

Discovery effort

Discovery effort is independent of severity, reproducibility, attribution, and whether AI tools assisted the work. Rate the reasoning needed to find and substantiate the mechanism—not the cost of executing the resulting attack:

• Trivial: direct local inspection, an immediately visible API or bounds error, or elementary arithmetic with no meaningful search.
• Moderate: focused source/specification review, a standard attack pattern, or a short calculation or experiment connecting the defect to its effect.
• Non-trivial: a multi-step candidate-specific argument, specialized cryptanalytic technique, or substantial experimental construction.
• Hard: a genuinely difficult attack chain, proof analysis, or recovery experiment requiring substantial new cryptanalytic insight or engineering.

Do not use Hard merely because the final attack is computationally expensive, the reproduced experiment is large, the severity is Critical, or the report was AI-assisted. If a later extension becomes the principal basis for the finding, reassess Discovery using the extension's reasoning.

Security targets

A finding is judged against the NGCC call as well as the specification's own claims. The canonical documents are published by ICCS.

For Round 1, the submitted specification and implementations are the evaluation target. An attack that requires a proposed modification does not change the submitted candidate's headline severity or status. Discussion of that modified variant belongs under Proposed fixes, clearly distinguished from evidence about the submission. An auditor-devised hypothetical variant may be discussed in a separate analysis note, clearly marked as hypothetical; it is not a candidate finding or a submitter-proposed fix.

Public-key algorithms (call):

• Classical security of 128, 256 and 512 bits, with quantum security of at least 80, 128 and 256 bits, respectively; an optional 384-bit classical level has a 192-bit quantum target (Submission Requirements §2(1)). "Complexity" covers both time and memory (ICCS feedback §5).
• Each signature key pair must support at least 2^64 different messages of up to 2^63 bits (§2(2)).
• A KEM's encapsulated key and a key exchange protocol's shared secret key must be at least as long as the corresponding classical security level (Submission Requirements §2(2)). An output shorter than its level is a direct NGCC-target shortfall, even when no separate IND-CCA or key-recovery attack is demonstrated.
• Security is evaluated against an attacker with signatures on up to 2^80 chosen messages or decapsulations of up to 2^80 chosen ciphertexts (Evaluation Criteria §1(2)). This is an evaluation ceiling for the attacker. For signatures, the operational per-key requirement remains 2^64 messages; the call gives no analogous per-key session cap for KEMs. Classify query-budget findings as follows:
• Critical: a concrete attack costs less than the required level for an attacker using at most 2^80 queries and within the per-key usage model that the candidate claims or supports. A collision probability or loose proof term alone is insufficient: the report must connect it to a primary break, such as forgery, key recovery, or distinguishing.
• High: despite a broader security claim, a candidate-specific parameter or proof bound covers fewer queries (typically 2^64), or becomes too loose at 2^80, but no concrete below-target attack has been shown. Use Status: Proof gap unless a specific attack path is identified. A generic loss shared by the underlying proof technique is not, by itself, this finding. Missing or insufficient analysis alone is never Critical.
• No finding solely from the query limit: the argument covers 2^80 queries; the query-dependent terms remain negligible at 2^80; or the candidate explicitly limits each key to at least the required 2^64 uses, makes no broader per-key claim, and no attack is shown within that limit. Record the operational limitation where it matters to interpreting the results.
• Signatures must be EUF-CMA or SUF-CMA; KEMs must be IND-CCA2 (§1(1)).

Hash algorithms (call):

• Collision security of at least h/2 bits and preimage and second-preimage security of at least h bits for an h-bit digest, with quantum attacks no cheaper than generic ones (Evaluation Criteria §1(2)).
• Digest lengths of 512 and 1024 bits (768 optional) and message lengths of at least 2^64 − 1 bits (Submission Requirements §2(1)). The targets apply to all supported lengths, whatever the specification claims.

Severity

Rate the strongest consequence supported by the report, including its stated preconditions and controls. Do not rate the feared consequence of an uncompleted attack.

A build or packaging problem alone is not a security finding, even at Low: record it in an evaluation or harvest note unless it causes a demonstrated security, availability, or interoperability failure in a submitted/supported build. A crash reachable through the submitted API may be Low when its only shown effect is termination; a failure that occurs only in a hand-edited or unsupported build does not qualify on that basis.

Critical

The report demonstrates a violation of a primary cryptographic security claim or applicable NGCC target, or gives a concrete attack bound below that target. Examples include:

• fresh-message forgery, full signing-key recovery, or universal verification;
• challenge-key recovery or a successful IND-CCA, IND-CPA, or key-exchange real-or-random distinguishing attack;
• collisions, preimages, or second preimages below the applicable bound;
• an enumerated key, randomness, or transcript space below the applicable level;
• a KEM or key-exchange output shorter than the classical level required by the call;
• a complete mathematical reduction of the claimed problem to work below the claim, even if that work is not currently practical.

A candidate-specific route with a quantified below-target cost may be Critical / Lead if material steps remain unvalidated. The report must name those steps and make clear that the cost is conditional, not a demonstrated break. A generic possibility or an unexplained extrapolation does not qualify.

NGCC requires a 512-bit classical level and permits an optional 384-bit level. A demonstrated 2^256 attack against a 512-bit claim is therefore Critical: practical feasibility is not required when the advertised security bound is violated.

For quantum attacks, a Grover-iteration count alone is not an end-to-end work estimate when the oracle is nontrivial. Count the oracle circuit, reversible arithmetic, memory and parallelization costs under the metric used by the claim. If those costs could close the reported margin and have not been bounded, classify the result as an analysis or proof gap rather than a confirmed below-target attack.

High

The report establishes a serious security failure but stops short of a complete primary-claim break. Typical cases are:

• a candidate-specific recovery/forgery method with one clearly identified engineering or scale step still unvalidated;
• a strong proof or parameter failure with a well-supported path to violating the claim, but without a complete end-to-end witness;
• attacker-controlled memory corruption with credible impact beyond process termination;
• a candidate-specific security argument that covers fewer signing or decapsulation queries than the call's 2^80 evaluation budget, without a concrete shortfall (see Security targets);
• a measured, repeatable secret-dependent oracle together with a candidate-specific recovery method, where only the observation channel or full-scale run remains open.

A demonstrated violation of a claimed property that the NGCC call does not require is High rather than Critical. For example, signature malleability that violates a claimed SUF-CMA property while leaving EUF-CMA intact is High, because the call accepts either EUF-CMA or SUF-CMA. Failing the designed security level of a required property is Critical.

Do not use High merely because a defect is expensive to repair. A side-channel finding can nevertheless be High when it exposes secrets directly and the construction lacks a portable constant-time realization without a substantial and justified loss of its advertised performance.

Medium

The report confirms a security-relevant defect or secret-dependent leakage, but does not demonstrate recovery, forgery, or a primary indistinguishability break. Examples include:

• a stable decryption-failure or reaction oracle without a completed recovery;
• repeated secret-dependent control flow or memory access for which a plausible local observation model exists;
• a substantive proof, binding, or conformance gap whose concrete attack consequence is unresolved;
• an attacker-supplied public key that forces or repeats an honest party's derived key, without breaking the scheme's honest-key security game;
• a side-channel repair that requires a material algorithmic rewrite or moderate performance/storage cost.

Low

The demonstrated impact is narrow and presently separated from a cryptographic claim violation. Examples include:

• denial of service, resource exhaustion, or an API contract error without memory disclosure or control-flow impact;
• source-level secret dependence with no measured channel or extraction, when a local mask, fixed-bound loop, small-table replacement, or existing constant-time path removes it;
• a limited robustness or interoperability defect;
• a candidate-specific cross-profile key-separation defect under a plausible shared-key composition, when no joint-security claim covers that composition;
• use of a generic random-bit-generator interface as a protocol PRG when correctness requires an exact seed-to-stream mapping that the scheme does not specify;
• a disclosed internal status whose existence alone does not defeat the claimed transform.

An easy fix may support Low when the demonstrated consequence is already narrow. It must not downgrade a demonstrated key recovery, forgery, or claim violation.

Info

Use Info for withdrawn records or non-security tracking entries. A live security finding should normally be Low or above.

Info may also record a reported property that is generic to a class of designs, such as the multi-ciphertext loss of every unsalted deterministic FO KEM, when the submission makes no stronger claim and the property has no candidate-specific consequence. Keep the cross-candidate discussion in an analysis note rather than singling out one submission with a higher severity.

A generic loss of a proof technique, shared across multiple schemes, does not by itself identify a candidate vulnerability. Examples are generic QROM/FO reduction terms and a Grover-iteration count without the oracle's full cost. Record these in a class analysis note, or retain a reported candidate ID as Info for traceability. The numerical calculation may be correct without being an attack. This exception does not turn a candidate-specific proof shortfall, parameter choice, false premise, or unvalidated claimed safety bound into Info. Apply the ordinary Medium/High proof-gap rules to those cases while stating clearly that no attack is demonstrated.

Info may record an attack requiring state-control capabilities outside the evaluated security model, such as seeding, cloning, resetting or rewinding the signer's DRBG, unless the submitted public interface or a formal security claim grants that capability. Randomized security experiments instead give each algorithm call fresh coins with the specified distribution. This rule does not cover ordinary reuse of scheme state exposed by the API, or an implementation that ignores, bypasses or predictably initializes its randomness source; classify those by their demonstrated consequence. An informal robustness remark in a submission does not create a formal claim. Use Status: Confirmed when the reported behavior was reproduced; reproduction confirms the behavior, not an in-model attack. State the out-of-model capability in the title and Exploitation line.

The same principle applies to cross-profile composition. A reproduced attack that requires one key to be installed simultaneously in distinct parameter profiles is not an attack on either profile's ordinary EUF-CMA experiment. Use Info when the composition also depends on an auxiliary non-default mode and the specification neither supports shared-profile keys nor claims joint security. Use Low as a hardening finding when shared key generation and formats make the reuse a plausible deployment mistake and missing profile separation is the only extra precondition. Use a higher severity only when a formal claim or a supported public interface covers the composition.

The ICCS KAT environment fixes drng.c and its seed-to-stream mapping, so a report may pin a KAT seed as a reproducible test fixture. Byte identity is not promised for a different secure RBG. One seeded witness establishes existence in the frozen implementation, not a general rate or an adversary's ability to choose that stream; broader claims require an analytic argument or multi-seed controls.

The supplied init_random_number/get_random_number interface is an external RBG interface, not a scheme XOF. Reinitializing or resetting a local instance from protocol data and relying on byte-for-byte replay uses that RBG as a deterministic PRG, KDF, or XOF. When correct decoding, verification, re-encryption, serialized-key interpretation, or cross-implementation behavior depends on the particular ICCS drng.c stream, record a Low Implementation finding unless a stronger consequence is demonstrated. A scheme-defined XOF with an explicit seed-to-stream mapping does not have this defect. If a specification defines and builds its own internal XOF but calls it a PRNG or DRBG, that is a labeling error and is not reported; the defect is reliance on the determinism of the external RBG. Use Layer: Implementation when the code wires a specified internal expander to the external RBG, and Layer: Design when the specification itself routes the expansion through the external RBG. Ordinary fresh-randomness calls and KAT seeding are not affected.

Side-channel severity

For timing, cache, branch, division, power, or address-trace findings, answer these questions in order:

1. Is the varying operand secret or derived from secret data at that point?
2. What can observe it: source inspection only, co-resident cache/process, local timing/power, or remote timing/API status?
3. Is the channel measured and repeatable, or only visible in source or machine code?
4. Is there a candidate-specific map from observations to a key, shared secret, plaintext, or forgery?
5. Has that map been executed end to end with the submitted implementation?

Use the resulting consequence, not the mere presence of a branch or table, as the primary severity determinant:

The table is a default, not a substitute for candidate-specific cryptanalysis. Public-value branches and lookups are not vulnerabilities.

Remediation burden supplies a second floor when no stronger consequence has been demonstrated: a local constant-time rewrite is Low, a material rewrite using known moderate-cost techniques is Medium, and a leak intrinsic to the advertised fast path with no supplied or known competitive constant-time realization may be High and Layer: Design. Use the higher of this floor and the consequence-based severity. Thus an easy fix does not lower a demonstrated recovery, and a hard design-level fix can raise a source-only leak.

Full recovery demonstrates that the implementation requires countermeasures and is therefore High even when the submission makes no side-channel claim. Critical is reserved for a demonstrated primary attack that additionally contradicts an explicit constant-time or relevant side-channel-resistance claim; merely supplying ordinary reference or optimized code does not imply such a claim.

Hash-function portability rule

For this audit, hash inputs and internal states are treated as potentially secret. Hash functions are routinely used on passwords, key material, transcripts containing secret contributions, and other confidential data.

A hash side channel is Layer: Design when all of the following hold:

1. the fast construction or the submission's advertised performance relies on secret-indexed tables, secret-dependent control flow, or another operation that is not portable constant-time;
2. removing that operation requires a different evaluation strategy rather than a local mask or canonical lookup replacement;
3. the portable constant-time strategy has a significant demonstrated or technically justified performance cost; and
4. no competitive portable constant-time path is supplied by the submitters or known as a well-known technique.

Hardware instructions may provide a safe fast path on some targets without curing the design-portability problem. A primitive that is constant-time only where a particular instruction-set extension is available is materially different from an ARX-style construction whose ordinary scalar operations are naturally constant-time across common processors.

Under this rule, a large byte-indexed table that is central to a hash's speed can support High / Design, even before a complete message-recovery experiment, when the address trace directly reveals message or state bytes and the only portable repairs impose a substantial performance loss. The report must identify the portable repair and measure its cost where feasible; an unmeasured slowdown must be labelled as an estimate.

Status

Status records confidence in exactly the claim made by the report:

• Confirmed: directly established by source/specification reasoning, a mathematical certificate, or a reproducible experiment with appropriate controls. Confirmed does not imply end-to-end exploitation; the Exploitation line must state the demonstrated boundary.
• Probable: the vulnerable path and consequence are strongly supported, but an important source, platform, or experimental step remains unchecked.
• Lead: a plausible candidate-specific attack or cost reduction still depends on a material unvalidated assumption or experiment.
• Proof gap: a stated theorem or reduction is invalid, incomplete, or covers an insufficient query range, but no attack of the claimed strength follows yet.
• Withdrawn: the original finding is false, duplicate, out of scope, or superseded. Keep its stable ID and use Severity: Info.

Confirmed may describe a confirmed source-level leak rated Low, while a High or Critical attack can remain a Lead. Severity and status must not be collapsed into one axis.

Layer

Assign the layer from the root cause, not from repair difficulty:

• Design: the normative construction, parameters, proof, or advertised portable performance profile contains the weakness. The finding applies to conforming implementations, or the submission's fast implementation relies on a construction choice whose portable constant-time replacement has a substantial justified cost. For hashes, apply the portability rule above.
• Implementation: the submitted source deviates from a sounder specification or introduces an ordinary API, parser, memory-safety, arithmetic, or randomness defect.
• Side-channel: the finding depends on observing timing, branches, cache addresses, division latency, power, faults, or another non-functional execution trace and does not meet the Design criteria above. Use this even when the specification claims the supplied code is constant-time; state that contradiction in the report.
• Evaluation: the issue concerns KATs, archive provenance, build metadata, reproducibility, or another evaluation artifact rather than the algorithmic security boundary.

The absence of a constant-time implementation ordinarily proves only that the submitted code is not hardened. To label the root cause Design, show that the specification mandates the observable behavior, that the advertised fast path structurally relies on it under the hash portability rule, or that the claimed performance/security profile cannot be retained by a portable constant-time implementation.

Remediation burden

Record remediation in the finding body when it helps evaluation:

• Local: a mask, fixed bound, canonicality check, small constant-time lookup, or already-supplied build path; limited expected cost.
• Moderate: a published constant-time decoder/solver, an expanded-key or caching change, or another substantial rewrite with credible moderate cost.
• Architectural: a change to the key/ciphertext format, core algorithm, or performance profile, or a repair with a measured prohibitive cost.

Use measurements where possible. Qualify an unmeasured cost as an estimate. State tradeoffs: storing an expanded secret changes memory and key handling; masked scans, sorting/permutation networks, dense multiplication, and constant-time elimination may change asymptotic or concrete cost. Do not call such changes local without bounding those costs.

For hash functions, remediation burden also informs the Design classification: a local masked operation or small in-register substitution remains a side-channel implementation defect, while replacing a performance-defining large table or data-dependent evaluation strategy can be a design-level portability defect.

Decision procedure

For each finding:

1. Trace public and secret inputs through the vulnerable operation.
2. State the exact observed behavior and attacker model.
3. Identify the strongest demonstrated consequence and its controls.
4. Compare that consequence with the applicable NGCC target and any explicit specification claim.
5. Assign Status from evidence, Severity from consequence, and Layer from root cause independently.
6. Describe remediation and its expected cost separately.
7. Keep limitations in the report: what was not measured, recovered, forged, or proved.

For contest pseudohash and pseudoXOF, assume ideal replacement primitives with the same external dimensions and parameters. A finding that disappears solely on that replacement is not publishable.