]> Institute of Information Engineering, Chinese Academy of Sciences

Beijing China icarid.liu@gmail.com

Institute of Information Engineering, Chinese Academy of Sciences

Beijing China luxianhui@iie.ac.cn

IRTF Crypto Forum Research Group Internet-Draft post-quantum cryptography NTRU KEM CFRG This document provides an informational review checklist for NTRU-family KEMs. It covers security claims, assumptions, reductions, concrete attack estimates, correctness and decryption-failure analyses, and implementation behavior for named specifications and parameter sets. It does not define a KEM interface or make recommendations among candidate KEMs.

Introduction The first post-quantum KEM deployment wave is centered on ML-KEM , but NTRU-family KEMs continue to be discussed because some have long public review records and some offer compact public keys or ciphertexts in particular parameter regimes. These properties motivate clear review criteria, but they do not by themselves imply a recommendation for use. This draft records family-level review questions for NTRU-family KEM specifications and security analyses. It follows the style of security-considerations work, such as draft-sfluhrer-cfrg-ml-kem-security-considerations-05, an active individual Internet-Draft last updated 2026-05-13 and active as of 2026-06-10, for ML-KEM . The schemes discussed in this document are reviewed as layered constructions. The NTRU-derived public key, usually represented by a short quotient such as h, is the object of private key recovery or public key indistinguishability analysis. The plaintext-hiding part can be viewed, for review purposes, as an RLWE- or RLWR-style encryption layer, or as a related ring-based encryption layer, in which the public ring element is the NTRU-derived h rather than an independently sampled public element. This is an analytical viewpoint: NTRU predates LWE and RLWE. Transform choices, decoding mechanisms, and decryption-failure behavior remain scheme-specific and security-relevant.

Review Checklist Conventions This document uses lowercase checklist language. Phrases such as "is expected to", "should", and "reviewers should check whether" are review guidance only. They are not BCP 14 keywords, do not create standards-track requirements, and do not define a standalone KEM interface.

Scope The scope covers KEMs whose security analysis relies on an NTRU-type relation. This includes schemes whose public key is of the form, informally, a short quotient in a polynomial ring, and schemes whose private-key recovery problem is naturally expressed as finding a short vector in an NTRU lattice. A similar layered analysis may apply to constructions in which private-key recovery is NTRU-like, while plaintext or ciphertext indistinguishability is analyzed using RLWE, RLWR, or a related ring or module assumption. The scope is family-level review criteria for KEM specifications and security analyses. The terms below are used throughout those criteria.

Terminology

NTRU-family KEM:

A KEM whose security analysis relies on an NTRU-type relation. The term is descriptive and does not imply that all such schemes share a single hardness assumption or a single proof strategy.

Public-key-security layer:

The layer that hides or protects the private NTRU trapdoor from the public key. In many NTRU-family KEMs this is analyzed as an NTRU search or decision problem.

Message-security layer:

The layer that hides the encapsulated secret, seed, message, or intermediate value under the public key. Depending on the scheme, this layer may be analyzed using RLWE, RLWR, subset-sum parity RLWE, or another assumption.

Correctness error:

The probability that decapsulation of a valid ciphertext generated by encapsulation under a valid public key outputs a shared secret different from the encapsulated shared secret.

DFR:

Decryption failure rate. This document uses DFR synonymously with correctness error for valid KEM encapsulations unless explicitly stated otherwise. Failure on malformed ciphertexts is a validation and oracle-resistance issue, not the same quantity.

Perfect correctness:

The property that valid encapsulations always decapsulate to the same shared secret under the specified algorithms and parameter sets.

Message-conditional DFR(m):

For a fixed accepted message or encoded plaintext m, Message-conditional DFR(m) = Pr[(pk, sk) <- KeyGen; ct <- Encrypt(pk, m): Decrypt(sk, ct) != m]. The probability is over key generation and encryption randomness of the underlying PKE. Although the KEM interface does not expose such a message parameter, KEMs built from a PKE by an FO-like, OAEP-like, SXY-like, or related transform inherit correctness requirements from that underlying encryption layer. Any proof loss or failure term associated with decryption failure should therefore state the corresponding PKE correctness quantity. This document also writes this quantity as DFR(m).

Average-case DFR:

E_m[Message-conditional DFR(m)], equivalently E_m[DFR(m)], for the stated distribution on the accepted message or encoded-plaintext space.

Worst-case DFR:

max_m Message-conditional DFR(m), equivalently max_m DFR(m), over the stated accepted message or encoded-plaintext space. In some NTRU-family analyses, the maximum is expected to be attained by a distinguished message pattern, such as an all-one message with no zero coefficients.

Classification of NTRU-family KEMs Review should classify a scheme according to the design dimensions in this section. The classification makes comparison possible without expressing a recommendation or maturity determination. The classification has two independent parts. The first is technical: which message-security layer is analyzed, which transform is used, and whether the KEM has perfect correctness or nonzero DFR. The second is evidentiary: what public review, standardization, implementation, and deployment evidence exists. The evidentiary part should distinguish public-review history, participation in a competition or standardization process, deployment evidence, national or regional selection, and recent research status. These categories are not interchangeable. For example, the NTRU-HPS/HRSS parameter sets from the NTRU NIST PQC Round 3 submission have multi-year public review records through the NIST PQC process . The individual CFRG document draft-fluhrer-cfrg-ntru-03 is expired and no longer active as of 2026-06-10; it is based on that submission, but includes additional parameter sets. For example, the draft reports the addition of ntruhps40961229 and ntruhrss1373 . Claims should state whether they apply only to the NIST-reviewed parameter sets or also to later additions, and what evidence supports each case. NTRU-HPS/HRSS standardization work is also reported in ISO/IEC JTC 1/SC 27 lightweight-cryptography work; review needs to identify the exact ISO/IEC text and status rather than relying on the family label . Other schemes have different evidence profiles. Streamlined NTRU Prime is one variant in the NTRU Prime submission, alongside NTRU LPRime. NTRU Prime was a third-round alternate PKE/KEM candidate in the NIST PQC process, but NIST did not select it for standardization or move it to the fourth round . NTRU+ was selected as a final PKE/KEM algorithm in the Korean Post-Quantum Cryptography Competition . Recent proposals such as BAT , NEV , DAWN , and CTRU/CNTR are included to identify scheme-specific review issues. Compactness or performance claims from those proposals are not treated as deployment guidance in this document. Scheme-specific notes for these entries appear in . The checklist items in the following sections are review prompts for discussion.

Parameter Scope A security claim applies only to a named specification, version, parameter set, and option set. For lattice KEMs, the relevant parameters usually include the polynomial degree or module dimension, modulus, secret distribution, noise distribution, compression or rounding parameters, and decoding radius. Changing one of these can change both correctness and attack cost. The parameter review should not treat these values as independent table entries. Lattice parameters interact: changing the modulus, distribution sparsity, or compression can improve size or performance while changing the best attack and the correctness margin. For each in-scope parameter set, the document is expected to state the intended classical and quantum security strength, the estimation model, and the margin relative to the target. Reviewers should check whether parameters are evaluated as a tuple. It is not sufficient to state that the ring dimension is large or that the modulus is conventional. The analysis should consider dimension, modulus, secret/noise distributions, entropy, decoding radius, ciphertext compression, and rejection rules together. If a parameter set is proposed primarily for compactness, the document should explain which margin is being spent.

Proof Proof review separates what is proved from what is assumed or estimated. A CCA-secure KEM claim usually rests on one or more underlying hardness assumptions, such as NTRU and RLWE. A scheme may also use a related assumption justified by a reduction or modeling step, for example a reduction that derives RLWR hardness from RLWE hardness under stated conditions. Separately, the scheme proof reduces the KEM security notion to those assumptions and other losses of the concrete scheme.

These reduction layers serve different purposes. An assumption-level reduction relates mathematical problems, such as RLWR and RLWE under stated conditions. A scheme-level reduction relates a construction to its assumptions, for example by applying a Fujisaki-Okamoto-style transform to a CPA encryption scheme. Once both layers are stated, concrete estimates should be reported for the instantiated bottom-level problem instances.

Security Notion and Reduction The scheme-level claim should say what security notion is claimed and how the construction reaches that notion from its underlying encryption mechanism. The proof discussion should keep four claims separate: underlying hardness assumptions, hardness reductions for those assumptions, the KEM proof reduction, and concrete attack estimates. A result in one layer is not a substitute for another. The claimed KEM security notion and proof model should be stated, such as ROM, QROM, standard model, or a mixed model.

Transform Transforms are security-relevant because they determine the reduction target, oracle behavior, and security property. The construction may use a Fujisaki-Okamoto-style transform, an FO-like transform, an OAEP-like transform, a SXY-like transform, or an Average-Case to Worst-Case (ACWC)-like transform. FO-like, OAEP-like, and SXY-like transforms are used, under their stated models and conditions, to obtain CCA-style security from an underlying CPA-secure encryption primitive. An ACWC-family layer can convert an average-case DFR analysis into a worst-case DFR bound for the encoded message space . If an error-correcting or auxiliary-code layer is part of the design, the proof should explain how that layer is bound to the KEM transform rather than treating it as an implementation detail. The construction path from the underlying encryption mechanism to the KEM should be identified. Examples include Fujisaki-Okamoto-style transforms, FO-like, OAEP-like, SXY-like transforms, or other transforms. If the construction uses an ACWC-family layer with GOTP/SOTP-style encoding, the document should state the concrete algorithms and explain how the layer is bound to the scheme-level reduction. NTRU+ is an example that uses ACWC2 with SOTP encoding .

Assumptions Assumptions are the mathematical problems on which the KEM relies, not proof reductions or concrete attack estimates for one parameter set. In NTRU-family designs this distinction matters because the public key or trapdoor part may be NTRU-like while the message-security layer is analyzed using RLWE, RLWR, ssp RLWE, or another related assumption. Each assumption should be precise enough for a reader to see what problem is claimed to be hard, whether a hardness reduction is being invoked, and whether attacks on one layer interact with attacks on another.

Assumption Inventory The problem inventory should identify exactly which NTRU, RLWE, RLWR, or related instances are relied on for the stated security claim to hold. Every hardness assumption used by the KEM should be identified. For NTRU-family KEMs this often includes an NTRU assumption for the public-key-security layer and an RLWE-, RLWR-, or related assumption for the message-security layer. The statement should include the exact problem variant, ring or module, modulus, distributions, sample form, parameter tuple, and search or decision form. The analysis should distinguish search assumptions from decision assumptions, average-case assumptions from worst-case reductions, and algebraic assumptions from generic lattice assumptions. If a hardness reduction is invoked, the document should state the theorem, direction, parameter restrictions, distribution restrictions, approximation factor, and loss. If a scheme relies on both NTRU and RLWE, RLWR, or a related layer, the document should state whether the instances are independent or algebraically coupled. The analysis should account for attacks that use both layers or reuse the same parameter tuple.

NTRU Assumption Details The NTRU layer controls public key or trapdoor security. Its review needs the exact algebraic setting and the actual secret distribution, because both lattice attacks and combinatorial attacks depend on them. The NTRU ring or algebraic structure, modulus, secret distribution, public key distribution, invertibility conditions, and key-generation rejection rules should be specified.

RLWE-like Assumption Details The message-security layer may be modeled as RLWE, RLWR, or a related variant using the NTRU-derived public element. The document should state whether this is a standard assumption, a reduced variant, or a scheme-specific modeling step. If the message-security layer is analyzed using RLWE, RLWR, or a related assumption, the document should specify the sample form, ring or module, modulus, secret distribution, error or rounding distribution, number of samples, and any structural restriction imposed by the NTRU public key. If the layer uses ssp RLWE or another nonstandard variant, the document should define that assumption and explain how it differs from ordinary RLWE.

Concrete Attacks Concrete security estimates answer a different question from reductions: for the instantiated parameter tuple, what is the cost of the best known attacks on the underlying problems? The answer depends on the attack families considered, estimator version, treatment of sparse or low-entropy distributions, and the BKZ/SVP cost model. Because these models continue to evolve, a security document should report explicit margin rather than merely meeting the target under one estimator run. An NTRU-family security document should present concrete estimates as reproducible review evidence, not as final theorems. The estimate should make clear which attack is being run, which lattice is being attacked, which model turns a BKZ block size into a bit cost, and which structural or algebraic attacks are outside the tool's default model. Dual and hybrid-dual estimates require particular care in security estimates. Small-modulus encryption layers can make hybrid-dual attacks appear competitive in estimator output while estimating message-layer security, but recent analyses have identified heuristic assumptions in dual-sieve and dual-sieve-FFT style estimates, and provable dual analyses can give different or more conservative costs . A report that relies on a dual or hybrid-dual estimate should therefore state whether the estimates it used are heuristic or provable. Distribution parameters enter different attack families in different ways. Lattice-reduction attacks are primarily sensitive to the realized scale of the secret, error, or auxiliary distribution, such as its standard deviation or target norm relative to the modulus and lattice dimension. Combinatorial attacks are primarily sensitive to the size and entropy of the sampled support. Hybrid attacks combine partial guessing with lattice reduction, so the analysis needs both views: the entropy cost of the guessed part and the changed lattice instance after that guess.

Estimation Tools and Cost Models Estimator output is useful only when it is reproducible and scoped to the problem being estimated. The report should make clear whether the run is estimating an NTRU public key instance, an LWE/RLWE/RLWR-style message-security instance, or a side-information instance. Concrete lattice-security estimates should be reproducible with a public estimator or public scripts. For NTRU-family KEMs, commonly relevant tools include the lattice-estimator for LWE, NTRU, and SIS estimates, and the leaky-LWE-Estimator when the analysis models leakage or side information. The lattice-estimator documentation includes NTRU parameter classes and attacks relevant to NTRU public-key instances, including overstretched parameter regimes. Therefore, a generic LWE estimate alone is not a sufficient check for an NTRU public-key claim . The report should state the tool, version or commit, script or command line, parameter encoding, non-default options, attack list, and any local patches. A document should not present estimator output without specifying the cost model. It should state the lattice-reduction cost model, such as ADPS16/Core-SVP or MATZOV-style , and the quantum cost model, such as Grover search or a quantum random walk.

Lattice-Reduction Attacks Lattice-reduction estimates are sensitive to dimension, modulus, target norm, and the cost model used to convert a block size into work. Those inputs should be visible rather than hidden inside an estimator printout. The estimate should state the lattice basis being attacked, the target vector, the target norm, the lattice dimension, the modulus, and the BKZ/SVP cost model.

Combinatorial and Hybrid Attacks Sparse or structured distributions also create search problems. A hybrid attack combines this search with lattice reduction, so both the entropy of the guessed part and the resulting lattice instance matter. For sparse or low-entropy secrets, the analysis should include combinatorial and hybrid attacks with exact size of support set.

Structural Attacks Ring and modulus choices can create algebraic structure that affects attacks, not only implementation speed. The review should state which ring is used or relied on. Recent work on module-lattice reduction gives a more specific ring issue. For power-of-two cyclotomic rings of the form x^n + 1 with n = 2^k, the cited module-BKZ analysis does not predict a smaller block size than the corresponding unstructured BKZ estimate. For other cyclotomic rings, the number field discriminant can give module-BKZ a sublinear blocksize gain, which corresponds to a subexponential speedup. This matters for NTRU-family schemes that use non-power-of-two cyclotomic rings, such as the tri-cyclotomic rings used by NTRU+ and by CTRU/CNTR . Tri-cyclotomic rings of the form Z[x]/(x^n - x^(n/2) + 1), with n = 2^i 3^j, need an additional coefficient-embedding check. In the power-of-two cyclotomic case, multiplication by x is a signed rotation of the coefficient vector. In a tri-cyclotomic ring, the reduction rule x^n = x^(n/2) - 1 means that multiplication by x is not a signed permutation in the usual coefficient basis. As a result, multiplication matrices may have rows with different Euclidean norms, and monomial multiples of the same secret may have different coefficient-embedding norms. Analyses of NTRU+ and CTRU/CNTR have discussed this ring shape in the context of polynomial multiplication and decryption-error behavior . The same issue is also relevant to concrete security estimates: the shortest target vector in the coefficient-embedding NTRU lattice may be a monomial multiple such as x^k * (g, f) or, for message-security estimates, x^k * (e, -s), rather than the unshifted vector. The expected variation may be small for a proposed parameter set, but the norm distribution over monomial multiples should still be measured or bounded and fed into the target norm used by lattice-reduction, combinatorial, and hybrid estimates. The review should discuss whether the ring, modulus, automorphism group, CRT decomposition, or subfield structure creates a known structural acceleration. Examples include weak rings, weak moduli, automorphism-based reductions, and attacks that use the ring structure to lower hybrid-attack complexity or otherwise change concrete structured-LWE estimates when applicable . The ring choice should be identified as power-of-two cyclotomic or another cyclotomic ring, and the analysis should account for known module-BKZ behavior for that ring when estimating lattice-reduction costs . If a message-security layer is modeled as Module-LWE, Ring-LWE, Module-LWR, Ring-LWR, or a sparse-secret variant over a structured polynomial ring, the document should evaluate attacks that use the algebraic structure in the attack algorithm, not only in the problem definition. Recent algebra-aware analyses include enhanced hybrid decoding attacks against Module/Ring-LWE that use the ring structure to accelerate guessing and decoding steps, and concrete comparisons between MLWE and unstructured LWE estimates . The analysis should state whether such techniques apply to the RLWE/RLWR-style layer used by the NTRU-family PKE or KEM construction, and how the conclusion changes under sparse or low-entropy secret and error distributions. If the scheme uses a tri-cyclotomic ring of the form Z[x]/(x^n - x^(n/2) + 1) or a ring of the form Z[x]/(x^n - x - 1) in which multiplication by x^i does not preserve the Euclidean norm, reviewers should check whether the security analysis accounts for the norms of all relevant monomial multiples of the target secret vectors, not only the displayed (g, f) or (e, -s) representative.

Parameters and Implementation Implementation review depends on the parameter tuple, randomness, sampler behavior, side-channel assumptions, test vectors, and interoperability behavior being specified together. Omitting one of these can invalidate proof assumptions or concrete security estimates. Review should identify the authoritative specification and parameter sets, explain option choices, state how distributions are sampled in real implementations, and identify the artifacts needed for reproducible testing.

Distribution and Sampling Sampling defines the distribution actually attacked. Security estimates should use the realized discrete distribution, including support, variance, entropy, rejection behavior, and side-channel properties, not only the name of the distribution. Every distribution used for secrets, errors, messages, coins, masks, or auxiliary values should be specified exactly. If a value is expanded from a seed, the expansion function, domain separation, byte order, rejection rule, and failure behavior should be specified. If a discrete Gaussian is used, the document is expected to specify the parameterization convention, support, truncation rule if any, exact or approximate sampling algorithm, and realized variance. Security estimates should use the realized discrete distribution, not only the nominal continuous variance. BAT gives a concrete example. If the centered discrete Gaussian has mass proportional to exp(-x^2/(2*sigma^2)) over all integers x, then its realized variance is sum_x x^2 rho_sigma(x) / sum_x rho_sigma(x). For the BAT value sigma = 0.596, this gives a realized standard deviation of about 0.588. The important point is that concrete estimates should use the realized distribution, including variance, tails, support, entropy, and sampler behavior. Implementers should not silently replace a specified distribution with a lower-variance or lower-entropy approximation. A faster sampler should be adopted carefully, since it may change variance, tails, support size, or entropy, which changes the security analysis. Secret-dependent sampler behavior needs to be addressed. Distribution samplers and rejection loops should not leak secrets through timing, memory access, iteration count, or other observable behavior unless a deployment-specific side-channel argument justifies the design.

Implementation Implementation considerations focus on preserving the proof assumptions and avoiding new oracles. Constant-time behavior, complete decapsulation checks, and zeroization are part of the security boundary, not optional engineering notes. Constant-time claims should be supported by both code review and tool evidence. Dynamic tools such as TIMECOP can be useful for this review: TIMECOP uses Valgrind's memcheck mechanism with annotated secret data to look for timing leaks caused by secret-dependent branches or memory accesses . Such tools are not a complete proof. They depend on the chosen annotations and test inputs, and TIMECOP's own documentation notes limitations such as variable-time CPU instructions and language/toolchain coverage. In NTRU-family KEMs, secret-dependent sampling, branching, or comparison can reveal whether a ciphertext was valid, whether decoding crossed a boundary, or which branch of the transform was taken. The document needs to identify those operations and give measures such as constant-time comparison, no externally distinguishable failure signal, constant-time fallback-key selection, and negative tests that exercise malformed inputs. When an FO or FO-like KEM includes a re-encryption check, that check is security-critical even when honestly generated ciphertexts decapsulate correctly without exposing a missing check in basic functional tests. Work on verifiable decapsulation reports that an HQC reference implementation flaw in this area went unnoticed for months and shows how confirmation codes can make faulty re-encryption visible in ordinary correctness tests . Such techniques may be considered by new designs or profiles, when the transform description and security proof account for them. Key generation, encapsulation, and decapsulation implementations are expected to avoid secret-dependent branches and secret-dependent variable-time arithmetic unless a deployment-specific side-channel analysis justifies them. Polynomial multiplication, base conversion, modular reduction, sampling, decoding, and comparison should be covered by that analysis. A document should report constant-time testing with TIMECOP, ctgrind, dudect, or a comparable tool, including tool version, compiler, optimization flags, platform, tested operations, and warnings. If a design uses confirmation codes or another mechanism intended to make skipped verification visible in tests, the document should describe how the mechanism is bound into the KEM transform and security proof. Secret keys and intermediate secrets should be zeroized when no longer needed. The document should identify long-lived secrets, ephemeral secrets, seeds, and decoded messages that require zeroization.

Decryption Failure Decryption failure is a central distinction inside the NTRU family. Some KEMs claim perfect correctness for the specified parameter sets. Others intentionally accept a nonzero decryption-failure probability and try to make that probability small enough, and model it explicitly. The review should separate mathematical correctness of valid encapsulations from behavior on malformed ciphertexts. A correctness bound says whether valid encapsulations decapsulate to the same shared secret. Invalid-input behavior is an oracle-resistance and side-channel question. Failure-based attacks connect the two when an adversary can make many decapsulation queries. DFR analysis here uses message-conditional DFR as the base quantity. In many Ring-LWE or Module-LWE (R/M-LWE) encryption layers, the decryption-error event is dominated by noise and rounding terms and may be independent of the encoded message. In NTRU-style encryption layers, the decryption error usually depends on the message. The analysis therefore should state whether DFR(m) is message-independent, averaged over a specified message distribution, or bounded by a maximum over the specified message space.

Correctness Statement Correctness is the claim that a valid encapsulation decapsulates to the same shared secret. That claim is separate from invalid-input behavior, but it depends on the exact algorithms, encodings, accepted-key conditions, and transform checks. The correctness claim should state whether the KEM has perfect correctness or a nonzero DFR. For perfect-correctness claims, it should give the algebraic reason no valid encapsulation can fail. For nonzero-DFR claims, the document is expected to state the DFR target, whether the bound is average-case or worst-case. Following mainstream schemes, the nonzero DFR should be smaller than, or approximately equal to, 2^-128 except in specific application scenarios with justification.

Average-Case and Worst-Case Bounds Average-case and worst-case DFR are derived from the message-conditional function DFR(m). The distinction matters when some messages have higher failure probability than others. The size of the gap is scheme-specific. In some NTRU-family DFR analyses, the message-dependent term is not the dominant contribution to decryption failure, so average-case and worst-case DFR may be close; NEV and DAWN are examples where the analysis should make that relationship explicit . In other designs, such as NTRU+ and BAT, ACWC-family coding is used to control the gap by converting an average-case DFR analysis into a worst-case bound for the encoded message space . A worst-case DFR relates to the reduction loss from CPA to CCA, so a scheme should not claim CCA security only from a negligible average-case DFR when the worst-case DFR is relatively large. If a DFR estimate assumes independence of ring coefficients, decoding events, or error groups, the document should justify the assumption or provide a conservative fallback bound.

Failure-Based Attacks Failure-based attacks are not only single-target attacks. If the coins or encryption randomness used in encapsulation are derived only from the encoded message, and not from the recipient public key or a collision-resistant identifier for it, then the same offline search for failure-prone messages may be reusable across many public keys. This is a multi-target concern: the attacker is not merely trying many ciphertexts against one key, but trying to amortize the search across a population of keys. NTRU+ records this issue in its change history and binds F(pk) into the encapsulation hashing for multi-target security . High decryption-failure probabilities have led to concrete attacks or attack analyses, including attacks against ss-ntru-pke and LAC . Failure boosting and multi-target analyses further show that the relevant review question is not only the average-case DFR, but also the cost of finding the first useful failing ciphertext under the attacker's query and target model . Many lattice KEM designs have used 2^-128 as a DFR target, but this is a review convention rather than a theorem that implies CCA security. Reviewers should consider it together with the maximum number of decapsulation queries and the number of distinct decapsulation keys exposed to those queries. Multi-target failure-based attacks should be analyzed. If encapsulation randomness is derived from the message but not from the public key, a public-key hash, or another collision-resistant public-key identifier, the document should explain why offline searches for failure-prone messages cannot be reused across targets. If such reuse cannot be ruled out, the derivation should bind the public key or identifier into the randomness derivation and the security proof. Reviewers should check that decapsulation does not expose a distinguishable failure signal through the external interface except where the KEM specification proves that the signal is safe. The usual safe behavior is to return a pseudorandom fallback shared secret using constant-time control flow.

Security Considerations This document is itself a security-considerations document. It does not specify a protocol, define a new KEM, or approve any KEM for use. Security guidance appears throughout the preceding sections, including the discussion of assumptions, concrete attacks, implementation behavior, and decryption-failure analysis. A scheme-specific document that uses these criteria is still expected to provide its own security considerations for the exact specification, parameter sets, and protocol contexts in scope.

IANA Considerations This document has no IANA actions.

Acknowledgments TODO acknowledge.

Cisco Systems mesur.io Brave Entrust TII NTT This draft document provides recommendations for the implementation of a post-quantum Key Encapsulation Mechanism (KEM) scheme based on the NTRU encryption scheme. The KEM is an existing cryptographic system; no new cryptography is defined herein. The well-defined and reviewed parameter sets for the scheme are defined and recommended. The test vectors are also provided. Cisco Systems National Institute of Standards and Technology Ericsson Individual Arqit Quantum Inc NIST standardized ML-KEM as FIPS 203 in August 2024. This document discusses how to use ML-KEM within protocols - that is, what problem it solves, and what you need to do to use it securely. This document describes a widely deployed hybrid key exchange method in the Secure Shell (SSH) protocol that is based on Streamlined NTRU Prime sntrup761 and X25519 with SHA-512. National Institute of Standards and Technology National Institute of Standards and Technology MATZOV Centre for Research on Cryptography and Security Post-Apocalyptic Crypto International Organization for Standardization Korean Post-Quantum Cryptography Competition

Scheme-Specific Notes This appendix gives scheme-specific background for the classification of NTRU-family KEMs. Scheme Evidence category Watchpoints NTRU-HPS NIST PQC; ISO/IEC work Parameter consistency NTRU-HRSS NIST PQC; ISO/IEC work Entropy loss from non-negative-correlation sampling Streamlined NTRU Prime NIST PQC alternate; sntrup761 deployment Concrete security of NTRU and RLWR on Galois group NTRU+ KpqC final selection Concrete security of NTRU on tri-cyclotomic ring BAT Research publication Discrete Gaussian realization NEV Research publication Concrete security of ssp RLWE DAWN Research publication Convolution-independence assumptions CTRU/CNTR Research publication Concrete security of NTRU on tri-cyclotomic ring Each entry still depends on exact parameter sets, version, and public review record; a family label alone is insufficient.

NTRU-HPS:

NTRU-HPS has NIST PQC public-review history for the parameter sets in the NTRU Round 3 submission . The main follow-up item is parameter consistency. The Round 3 submission contains multiple HPS parameter sets, and draft-fluhrer-cfrg-ntru-03, an expired individual draft, reports the addition of ntruhps40961229 . As of 2026-06-10, that draft is no longer active. Security claims need to name exactly which HPS parameter sets are in scope and map each claim to the corresponding specification, parameter name, and review record.

NTRU-HRSS:

For the NIST-submitted parameter set, NTRU-HRSS has NIST PQC public-review history. The expired individual Internet-Draft draft-fluhrer-cfrg-ntru-03 is earlier IETF draft work related to that submission, but it includes additional parameter sets; for example, it reports the addition of ntruhrss1373 . The NTRU specification defines HRSS key-sampling spaces using T+, where T+ outputs ternary polynomials satisfying the non-negative correlation property . Because this predicate narrows the sampled support, a security analysis needs to account for its effect on support size and entropy when estimating combinatorial and hybrid attacks. That predicate is an attack-model input. Later HRSS parameter additions need separate evidence.

Streamlined NTRU Prime:

Streamlined NTRU Prime is part of the NTRU Prime submission, which NIST treated as a third-round alternate PKE/KEM candidate. NIST did not select NTRU Prime for standardization or move it to the fourth round . The sntrup761 instance also has deployment evidence in SSH, including the Informational RFC for the hybrid method sntrup761x25519-sha512 . Review still needs to name the Streamlined NTRU Prime instance in scope and its exact security assumptions, transform, and correctness model from the authoritative specification.

NTRU+:

NTRU+ represents a different evidence category: selection as a final PKE/KEM algorithm in the Korean Post-Quantum Cryptography Competition. The cited document is the January 30, 2026 KpqC final version . The evidence category is distinct from IETF or CFRG approval and from multi-year deployment evidence. The scheme-specific follow-up is whether the concrete security estimate for the NTRU layer accounts for the tri-cyclotomic ring shape.

BAT:

BAT is a sampling example for recent NTRU-family designs. It specifies discrete Gaussian secret-key sampling, so the realized distribution is a security input, not only an implementation detail. The analysis should account for the difference between the nominal Gaussian parameter and the realized discrete standard deviation, as discussed in the Distribution and Sampling section.

NEV:

For NEV, the relevant issue is the ssp RLWE assumption. The security analysis needs to explain whether it uses the variant NEV' based on the ssp RLWE assumption rather than standard RLWE, and provide a concrete security analysis of that assumption.

DAWN:

For DAWN, the relevant issue is DFR. The security analysis should identify where independence assumptions for convolution coefficients enter the DFR calculation, whether those assumptions are heuristic, and what conservative fallback bound is available.

CTRU and CNTR:

CTRU and CNTR are discussed together because the cited journal article presents both constructions. The article describes CTRU as relying on NTRU and RLWE assumptions and CNTR as relying on NTRU and RLWR assumptions. The KEMs use the generic prefix-hashing FO transform FO^perp_{ID(pk),m} in Duman et al. , while is the construction paper for CTRU and CNTR. Review should separate CTRU from CNTR wherever the assumption inventory, decoding, rounding, DFR analysis, transform instantiation, or implementation constraints differ, and should note the tri-cyclotomic concrete-security check described in the Structural Attacks section.