| Internet-Draft | NTRU-family KEM Considerations | June 2026 |
| Liu & Lu | Expires 24 December 2026 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 24 December 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
The first post-quantum KEM deployment wave is centered on ML-KEM [FIPS203], 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 [I-D.sfluhrer-cfrg-ml-kem-security-considerations].¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
The property that valid encapsulations always decapsulate to the same shared secret under the specified algorithms and parameter sets.¶
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).¶
E_m[Message-conditional DFR(m)], equivalently E_m[DFR(m)], for
the stated distribution on the accepted message or encoded-plaintext
space.¶
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.¶
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 [NTRU-R3] have multi-year public review records through the NIST PQC process [NISTIR8413]. 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 [I-D.fluhrer-cfrg-ntru]. 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 [NTRU-ISO-WORK] [ISO29192-4-AMD2].¶
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 [NISTIR8413] [NTRU-PRIME]. NTRU+ [NTRU-PLUS] was selected as a final PKE/KEM algorithm in the Korean Post-Quantum Cryptography Competition [KPQC-RESULTS]. Recent proposals such as BAT [BAT], NEV [NEV], DAWN [DAWN], and CTRU/CNTR [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 Appendix A. The checklist items in the following sections are review prompts for discussion.¶
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 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.¶
[ CCA KEM claim ]
|
| scheme-level reductions
v
[ CPA PKE or related encryption ]
|
| scheme-to-assumption reductions
v
[ Variant assumptions: RLWR, ssp RLWE ]
|
| assumption-level reductions
v
[ Base assumptions: NTRU, RLWE ]
Concrete estimates apply to bottom-level problem instances.
¶
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.¶
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.¶
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 [ACWC-NTRU]. 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 [NTRU-PLUS].¶
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.¶
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.¶
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.¶
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 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 [DUAL-SIEVE-WORK] [PROVABLE-DUAL-LWE]. 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.¶
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 [LATTICE-ESTIMATOR] [LATTICE-ESTIMATOR-DOCS] for LWE, NTRU, and SIS estimates, and the leaky-LWE-Estimator [LEAKY-LWE-ESTIMATOR] [DDGR20] 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 [LATTICE-ESTIMATOR-DOCS]. 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 [ADPS16] or MATZOV-style [MATZOV22], and the quantum cost model, such as Grover search or a quantum random walk.¶
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.¶
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.¶
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
[MODULE-BKZ].¶
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
[NTRU-PLUS] [CTRU-CNTR]. 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 [RING-HYBRID-2026] [MLWE-LWE-GAP].¶
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 [MODULE-BKZ].¶
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 [RING-HYBRID-2026] [MLWE-LWE-GAP]. 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.¶
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.¶
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 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 [TIMECOP-TOOLS] [TIMECOP]. 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 [VERIFIABLE-DECAPS]. 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 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 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 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 [NEV] [DAWN]. 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 [NTRU-PLUS] [BAT] [ACWC-NTRU].¶
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 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
[NTRU-PLUS].¶
High decryption-failure probabilities have led to concrete attacks or attack analyses, including attacks against ss-ntru-pke [DFR-SS-NTRU] and LAC [DFR-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 [MULTITARGET-DFR]. 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.¶
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.¶
This document has no IANA actions.¶
TODO acknowledge.¶
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 has NIST PQC public-review history for the parameter sets in
the NTRU Round 3 submission [NTRU-R3]. 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
[I-D.fluhrer-cfrg-ntru]. 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.¶
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
[I-D.fluhrer-cfrg-ntru]. The NTRU specification defines HRSS
key-sampling spaces using T+, where
T+ outputs ternary polynomials satisfying the
non-negative correlation property [NTRU-R3]. 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 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 [NISTIR8413]. The sntrup761 instance also has deployment evidence in SSH, including
the Informational RFC for the hybrid method
sntrup761x25519-sha512 [RFC9941]. 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+ 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 [NTRU-PLUS]. 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 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.¶
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.¶
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 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.
[FO-PREFIX-HASHING], while [CTRU-CNTR] 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.¶